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PREFACE 


This document repreaente a preliminary plan for the Space 
Telescope Observatory Management System (STOMS) Test and 
Verification (TAV). The objective of this effort is to 
provide a working model to be used by the TAV contractor in 
performing test and verification activity. 

The scope of this document includes s definition of all the 
STOMS elements including organizations, support resources, 
interfaces and test tools. The methodology, Including test 
conditions and scenarios, has been developed: outlines for 
teat plana and procedures have been provided; and, a 
procedure for failure reporting and corrective action has 
been recommended. A test organization including detailed 
definitions of responsibilities summarizes the test plan. 

A very preliminary schedule for the TAV has be^n developed 
being cognizant of the other test and simulation activities 
occurring in the same period and competing for support 
resources. The entire TAV plan has been developed with full 
awareness of other testing activities in order to reduce 
conflicts and to maintain continuity. 

The appendices contain supportive information including a 
number of matrices showing the relationship between the 
various support elements and the functional requirements, 
descriptions of test systems, descriptions of test events 
and Controlled Test Data Set examples. 

This document is a recommended TAV plan developed by ISN in 
conjunction with NASA Code 500. No specific points have 
been singled out as being a recommended approach over an 
alternative. 
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During the course of this study some data was found to be 
not available or In conflict with previously published data. 
When data was missing the term TBD (To Be Determined) has 
been used In the test. If avallalble data conflicted, the 
term TBR (To Be Resolved) has been used. 
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SECTION 1 


INTHODOCTION 

The Space Telescope (ST) Mission Operations Ground System 
(MOGS) Is comprised of two major systems that will provide 
full ground support and data processing. These systems, the 
ST Observatory Management System (STOMS) and the Science 
Operations Ground System (SOGS), are comprised of a number 
of Interconnecting facilities. To ensure that the MOGS will 
function smoothly, the STOMS and SOGS and their related 
elements and Interfaces must be carefully Integrated and 
tested. The MOGS Integration and Test (I&T) will encompass 
all I&T activities associated with combining the major ST 
ground system elements into the MOGS and -^ith verifying MOGS 
operation. 

This document pertains only to the STOMS Test and 
Verification (TAV) which will be performed prior to the MOGS 
liT and will consist of testing and validating all of the 
STOMS facilities and their interfaces. The SOGS will 
undergo similar teats and validation followed by integratiori 
of STOMS and SOGS into the MOGS. To insure the STOMS TAV 
planning responds fully to the overall MOGS requirement, 
Section 2 provides an overview of tlie entire ST Ground 
System with special emphasis on the STOMS TAV and 
interfaces. Section 3 describes the STOMS TAV Methodology 
including teat conditions and scenarios. The data 

transmitted across each of the STOMS interfaces are 
categorized in Section 4. For each data category, detailed 
descriptions of the individual data sets are also provided. 
Section 5 specifies the functional requirements of the 
individual interfaces which must be tested during the STOMS 
TAV. Section 6 identifies and describes the support 
elements for TAV. The interrelated testing activities frr 
STOMS implementation are presented in Section 7 with an 
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asaoolated t«st sohedule. Section 8 desorlbea failure 
reporting and correction procedurea appropriate for STOMS 
TAV. Section 9 identifiea the format and content 
requlrementa for individual teat plana and procedurea to be 
furniahed by the individual contractora/projeota. Section 
10 deaoribea the teat organization and reaponaibilitiea of 
the teat peraonnel, configuration control procedurea to be 
followed, and teat evaluation aotivitiea* Dooumenta uaed 
in the development of thla plan are deacribed in the 
Bibliography* 
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SECTION 2 


OVERVIEW 

Th« ST l3 « larg«» T«rsatil«, high resolution telesoope with 
a oonplement of five scientific Instruments Including two 
cameras, two spectrographs, and a photometer. The extremely 
accurate and stable attitude control system which will point 
the ST will also be employed for making precise astrometric 
measurements. Operation of the ST In the absence of the 
atmosphere will allow observations In the visible region of 
the spectrum to be made at the full resolution of the 
telescope. In addition, the absence of atmosphere will 
permit observations to be made at wave lengths Inaccessible 
to terrestrial observatories. The ST will be operated as an 
orbiting astromonicai facility and will provide 
observational capabilities which greatly exceed those of any 
existing or planned ground based telescopes. 

Du( for launch in 1985, the ST will be Inserted into a 
nominal 500 km altitude and 28.5 degree Inclination orbit by 
a Spaoe Shuttle launched from Kennedy Space Center. This 
will be the first free flying payload for the Space Shuttle 
and will be revisited by the Shuttle and be provided with 
on-orbit maintenance by astronauts. Spacecraft subsystem 
components and complete science Instruments can be replaced 
during orbital maintenance. The ST will be retrieved 
periodically by the Space Shuttle and returned to the ground 
for ma,1or servicing, instrument updating, and telescope 
refurbishment. The operational life of the ST Is at least 
15 years. 
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The NASA Space Telescope ranks as one of the largest space 
programs undertaken by the U.S. It will be operated In a 

manner very similar to the world's major ground-based 
observatories, but will be capable of observing celestial 
bodies which are 50 times fainter and 7 times more distant 
than those visible to earth-based telescopes, possibly 
seeing as far as 14 billion light years. 

2.1 ST GROUND SYSTEM 

The ST will be controlled by the space telescope ground 
system shown In Figure 2-1. The various elements of 
this ground system, the functions performed by each 
element, related terminology and contractors are 
described In the following paragraphs. 

2.1.1 STOMS . The STOMS consists of the Payload 
Operations Control Center (POCC) and the Data 
Capture Facility (DCF), both unique ST facili- 
ties provided under several contracts. The 
POCC will be located at the GSFC, and will 
direct, control, and monitor all spacecraft 
scheduling and operations. The DCF, also locat- 
ed GSFC, will record (capture) science data for 
retransmission to the SOGS. 

The POCC is being developed under two separate 
contracts: Preliminary Operations Requirements 

and Test Support (PORTS) contract and the POCC 
Applications Software System (PASS) contract. 
The PORTS contract will provide for the complete 
hardware and systems level software 
implementation of the POCC, for execution of the 
mission control functions, including both an 
on-line command and control system and an 
off-line support computing system. The PASS 
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contract will contribute to support of the 
mission control function and provide the 
additional software necessary to provide the 
sub-functions of attitude determination, 
command management, subaystem management, target 
pointing support, and mission scheduling. 

The various NASA institutional facilities 
included in the STOMS will provide the 
communications capability required for uplinking 
commands and receiving downlinked data, oapture 
downlinked science data, and provide certain 
computational support for ST operations. These 
NASA facilities interfacing with the STOMS are 
the Network Control Center (NCC), the NASA 
Ground Terminal - NASA Communications Network 
(NGT-NASCOM) , the Tracking Data Relay Satellite 
System (TDRSS) , the Operations Support Computing 
Facility (OSCF) and the dedicated Marshall Space 
Flight Center (MSFC) supplied ST simulator. 


2.1.2 SOGS . The SOGS Is comprised of the Science 
Support Center (SSC), co-located with the POCC 
at the GSFC, and the hardware and software 
located at the ST Science Institute Facility (ST 
ScIF) at Johns Hopkins University. The combined 
SSC and ST ScIF nardware and software specified 
above will be developed under the SOGS contract. 
(The Guide Star Selection System (GSSS) and 
science data analysis software 1s an exception 
to this and will be developed under a separate 
contract. ) 
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The SSC will perform detailed science 
scheduling, manage the transfer of real-time and 
near real-time data between the SSC and the ST 
ScIF, support the POCC In system anomaly 
Investigation, and conduct limited real-time 
science operations. The ST ScIF will conduct 
the program to support scientific observations, 
including the selection of scientific programs, 
observation planning, science data analysis, and 
product generations. 

2.1.3 Related Terminology. Some of the terms used in 
the ST project are further defined In the 
following paragraphs. 

The construction of the building at Johns 
Hopkins University, Baltimore, housing the ST 
Science Institute (i.e., the ST ScIF), the 
development of the GSSS hardware and software, 
the development of the science data analysis 
software and the operation of the SOGS will be 
accomplished under the ST Science Institute (ST 
Scl) contract. 

The ST Scl? hardware and software procurred 
under the SOGS contract, In combination with 
GSSS hardware and software, and the science 
data analysis software procurred under the 
the Science Institute contract are collectively 
referred to as the ST ScIF. 

The combination of the POCC and the SSC Is 
collectively referred to as the Space Telescope 
Operations Control Center (STOCC). 
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Figure 2-2 supports Figure 2-1 in defining these 
interrelationships of the MOGS elements* 

2.1.U ST Ground System Contractors. The contactors 
Involved with the STOMS and SOGS are the Support 
System Module (SSM) contractor, Lockheed Missile 
and Space Company, Inc. (LMSC); the PORTS 
contractor, Ford Aerospace and Communications 
Corporation (FACC) ; the PASS contractor, 
Computer Sciences Corporation (CSC); the Mission 
Operations Contractor (MOC); LMSC; the ST Scl 
contractor, John Hopkins University (JHU); and 
the SOGS contractor, TRW Inc. The primary 
hardware and software development contractors 
for the STOMS are SSM, PORTS, and PASS. The 
SOGS contractor has responsibility for the SSC 
and ST ScIF systems interfacing to the STOMS. 
The MOC and the Mission and Data Operations 
Directorate (MD40) personnel share operational 
responsibility for the PCCC with the MOC 
having primary responsibility for ST flight 
operations . 

The Networks Directorate has operational 
responsibility for the NCC and MGT-NASCOM. The 
development and operational responsibility for 
the ST Simulator is part of the Project 
Management (MSFC) responsibility. The ST Scl 
contractor will operate the SCC and ST ScIF 
interfacing the STOMS. 
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ELEMENTS OF ST MISSION OPERATIONS GROUND SYSTEM (MOGS) 


2.2 


STOMS TEST AND VERIFICATION (TAV) 


The functional requirements to be met under the TAV are 
not only those Imposed for each system element within 
STOMS, but also the requirement that these elements, 
when combined, function as a total system. The major 
element Interfaces to be tested under the TAV event, 
are the POCC, DCF, NGT-NASCOM, NCC, OSCF, and the MFSC 
ST Simulator. Under the Implementation effort, the 
POCC functional requirements are tested during the 
PORTS and PASS Integration and teat events. The DCF, 
MFSC ST Simulator and ST functional requirements are 
also tested under their specific Integration and test 
events or, in the case of ST itself, during ST Assembly 
and Verification (A4V) at LMSC. 

The NASA institutional elements, l.e., TDRSS, 
NGT-NASCOM, NCC and the OSCF are multlmlaslon support 
facilities and will have been tested as Individual 
elements and exercised considerably by similar 
satellite projects prior to the TAV. However, these 
elements will be tested for ST unique functions during 
the TAV of other elements within the STOMS. 

The functional requirements for the SOGS elements will 
be tested as part of the SOGS contract. STOMS TAV will 
concern Itself with interface TAV as described in 
sub-section 2.2.2 of this section. 

The STOMS TAV is part of the ST implementation effort 
and encompasses all activities associated with 
combining the major elements into the STOMS and with 
verifying STOMS operation. The TAV activities will be 
conducted in three phases. Phase I will consist of 
sequentially testing the Interfacing hardware and 
software and verifying that the specific interface 
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balng tested complies with the related Interface 
Control Document (ICD). The use of both real and 
simulated Scientific Instrument (SI) data, spacecraft 
data, commands schedules and Controlled Teat Data Sets 
(CTDS) will be required* 

Phase II will be a systems engineering teat to verify 
the various command, data and engineering strings as 
well as support functions. This will be a total teat 
Including verification of system reaction to anamolles. 
CTDS will Include predefined error Inducing data. 

Phase III will be a mission oriented system performance 
teat to verify full computer loading and timelines. 
All STOMS elements and Interfaces will be exercised In 
a near normal operational environment. The ability of 
the STOMS to respond to element and sub-element 
failures will also be tested during this phase. Refer 
to Figure 2-3, STOMS Development and Implementation, as 
an illustration of the relationship between the TAV 
phases and other portions of the STOMS implementation. 
Although the TAV contractor Computer Technology 
Associates (CTA) will have full responsibility for the 
three phases of the TAV, the contractor will also be 
Involved In the pre- and post-TAV activities. The 
contractor will be represented In the element testing 
and the establishment of CTDSs. The contractor will 
identify all CTDSs required and develop those not 
provided. The TAV contractor will also be 
representative in post-TAV which would include STOMS 
operational evaluation and the MOGS I&T. 
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SPACE TELESCOPE OBSERVATORY MANAGEMENT SYSTEM 



FIGURE 2-3. S'FOMS DEVELOPMENT AND IMPl.EMENTATION PLAN 






2.2.1 3T0M3 Internal Interfaoe TAV. Th« data flows 

between the 3T0MS system elements are shown in 
Figure 2-^. As previously Indloated, the 3T0M3 
TAV will be preceded by an extensive series of 
tests performed at the element level. The 
hardware and software provided under the P0RT3 
contract and the software provided under the 
PA33 contract will be separately Integrated and 
tested by the respective contractors. The DCF 
and other Institutional facilities which are a 
part of the 3T0M3, will undergo functional 
testing by the GSFC. 

Other tests such as the Verification and 
Acceptance Program (VAP) and the A&V at L3MC, 
developed and to be exercised for specific 
purposes, will perform a secondary function of 
testing some Interfaces. These testa are not 
part of the TAV; however, data developed during 
these testa could be used as TAV CTD3 (TBD). 

The test requirements, plans, and procedures for 
each Interface teat will be prepared by the same 
organization that has developed and maintained 
the related ICD. The PORTS contractor will 
develop and maintain the ICDs between the DCF 
and the On-Line System (0NL3), between the MSFC 
Simulator and the POCC ONLS, between NGT-NASCOM 
and the ONLS, between the SSC and the ONLS, 
between the NCC and the ONLS and between 
external telemetry users and the ONLS. The 
PORTS contractor will also develop and maintain 
the ICD between the SCC and the Off-Line System 
(OFLS). The PASS contractor will develop and 
maintain the ICDs between the SSC and the POCC, 
between the Mission Planning Terminal (MPT) and 
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FIGURE 2-4. STOMS INTERNAL INTERFACES 



; the OFLS, between the OSCF and the OFLS, and 

I, between the NCC and the MPT* 

I The character of the data transmitted across 

each of the interfaces involved is specified in 
I detail in Sections 4 and 5. 

2.2.2 STOMS External Interface TAV. Another function 
of the TAV is to test the Interfaces external to 
the STOMS (Figure 2-5). The first STOMS 
external interface is between the DCF and the ST 
ScIF. All captured SI science data are 
transmitted across this interface from the DCF 
via NASCOM to the ST ScIF Post Observation Data 
Processing System. In the second STOMS external 
interface, SI engineering data are transmitted 
I ' to the associate contractor from the POCC. The 

third STOMS external Interface is with the SSC, 
and is comprised of two sub-interfaces: the SSC 

to POCC-ONLS interface and the science 
scheduling subsystem to POCC-OFLS interface. 
Four categories of data are transmitted over the 
SSC/ONLS interface: (1) data from at least 20 

percent of all science observations transmitted 
from the ONLS to the SSC, (2) engineering data 
sets transmitted to the SSC, (3) real-time 
command requests transmitted by the SSC and (4) 
voice and video from the ONLS and the SSC. Four 
categories of data are transmitted over the 
SSC/OFLS interface: (1) program command 

requests to the OFLS, (2) Iterative, two-way 
transmission of science mission specifications, 
(3) ephemeris data transmitted from the OFLS, 
and (4) spacecraft operations data transmitted 

i 

from the OFLS. 

; [' 

I - 

i [ 

:4 » 


2-13 



< 

Jl 

s 

> 

UJ 

> 

O 


X 

UJ 


c 

CO 




UJ 

> 


X 

5 

z 

o 


U1 

a 

< 

< 

3 


Ui 

O 

Z 


FIGURE 2-5. STOMS EXTERNAL INTERFACES 






More detail on the character of these data as 
well as the data between the NASA facilities and 
STOMS, Is presented In Section 4 and 5* 
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SECTION 3 


METHODOLOGY 

The STOMS TAV methodology la a planned approach to teatlng 
the major elementa oomprlalng the STOMS, and performing auch 
teata aa are required to verify that the operation of the 
total ayatema aatlaflea all eatabllahed requlrementa . Each 
of the major elementa will be teated prior to the STOMS TAV. 

The STOMS TAV actlvltlea will be performed In three phaaea. 
The Interface hardware and aoftware will be teated during 
Phaae I. Phaae II will conalat of teatlng the varloua 
command, data, and engineering atrlnga until a total teat la 
completed. Phaae III will be mlaalon oriented and be a 
total ayatem performance teat. Teatlng In all three phaaea 
will verify compliance of the Interfacea and elementa to the 
applicable requlrementa documentation, apeclf Icatlon , or 
ICD. Compliance verification la crucial to aucceaaful teat 
plan development. Thla approach Inaurea compliance through 
traceability from controlled document requlrementa to teat 
procedure requlrementa. Figure 3-1, STOMS Hequiremen ta/Tea t 
Procedure In terre la tlonah ip , Indxcatea how the STOMS 
requlrementa will be traceable to a teat procedure. 

3.1 PRE-TAV ACTIVITY 

The TAV contractor will be repreaented in element 
teatlng prior to the actual TAV phaaea. Thla prephaae 
activity will be of a TAV preparatory nature to enaure 
continuity between Integration, teatlng and 
verification. The eatabllahment of CTDS at thla point 
will enaure the validity of teat Input data during TAV. 
Completion of TAV teat execution procedurea would alao 
occur at thla time. 
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STOMS 

REQUIREMENT 



FIGURE 3-1 STOMS REQUIREMENTS /TEST PROCEDURE INTERRELATIONSHIP 
















3.2 TAV PHASE I, INTERFACE TEST 


The Internal and external interfaces of the STOMS were 
shown in Figures 2«4 and 2-5, respectively. During 
Phase I, compatibility across each individual Interface 
will be verified by means of separate tests of the 
commands, data and acknowledgements specified for each 
interface. These tests will often require the use of 
CTDS, testing software, and hardware test units to 
simulate portions of ground system elements which nay 
not be available. 

As an example of the methodology of separately testing 
the individual STOMS interfaces, the MGT-NASCOM to POCC 
interface will be described. There will be a discrete 
channel for the spacecraft commands and for the 
telemetry stream. On the return channel, the data 
transfer will be non-contlguous burst-block transfer. 
The correct blocking, format, mode/ flag/ ind i ca tor 
setting, and bit error-rate (BER) will all be measured 
in the POCC and compared to the specifications. 
Command data originating at the POCC will be checked to 
verify format as well as correct block and bit transfer 
rate. Where possible multiple operational 

configurations will be simulated to provide a more 
comprehensive teat. 

3.3 TAV PHASE II, SYSTEM ENGINEERING TEST 

Phase II will comprise a number of testa each designed 
to ensure the desired end product as well as to verify 
all elements and interfaces involved with the genera- 
tion of that end product. As an example, the ST 
command function would involve a string of elements 
and their interfaces, from the SSC to the ST. Other 
strings would include science data flow, ST engineer- 


3-3 


Ing data, SI engineering data, scheduling data, and 
support data. Each of these strings would Include 
subsets, each tested in the same fashion. All data 
or commands will be traceable from origin to final 
termination through as many elements as possible. 

The tests conducted during Phase II will include a 
comprehensive set of test cases and conditions intended 
to expose system, hardware, and software limitations. 
As an e?;3mple, data with marginal signal levels would 
test the system's capability to recognize data errors 
and to recover properly. 

The systems engineering attributes of reliability and 
maintainability will be determined and recorded during 
Phase II in conjunction with each teat established. 

3.4 TAV PHASE III, SYSTEM I'ERFORMANCE TEST 

Tests will be performed during Phase III using all of 
the major STOMS elements with the objective of 
exercising and verifying the operation of the total 
STOMS. This phase will include testing across multiple 
interfaces and will Involve the use of simulated data 
and CTDS. Tests will be comprehensive and will 
exercise as many hardware components and program 
statements as practicable. Timelines will be verified 
against mission requirements and under full load 
conditions . 

Phase III is mission oriented with emphasis on 
exercising the total system in a closely simulated real 
time environment. 
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3.5 POST-TAV ACTIVITY 


After completion of the TAV, the TAV contractor will 
aaaume a supportive role In the subsequent STOMS test 
and simulation events. These events Include mission 
operations procedure development, MOGS lAT, training 
and simulation. 

3.6 TEST CONDITIONS 

The three phases of STOMS testing, In addition to the 
planning and execution of the required tests, must 
necessarily include the evaluation of test results, 
with such evaluation essentially required in real-time. 
The evaluation of test results will entail a comparison 
of the results actually obtained In a particular test 
with the anticipated results described In the test 
plan. The Immediate detection of anomalous test 
results will enable any necessary regression testing to 
be performed, prior to a test configuration being torn 
down. Input data (e.g., magnetic tapes of simulated SI 
data) will be evaluated In terms of its usability 
(e.g., format, content, fidelity, and completeness) 
prior to their utilization for test purposes. This, 
along with control of the test data sets, will be a 
primary function of the TAV contractor. 

3.7 TEST SCENARIOS 

Test scenarios for Phase I and Phase II have been 
developed and are depicted in Tables 3-1 and 3-2. The 
Phase I scenario indicates a possible sequential order 
for verification of the STOMS interfaces. This 
sequence begins with supportive data being transmitted 
to the POCC and DCF, prior to the interface between 
the POCC and DCF being tested. 
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TABLE 3-1 


Test 1 . 


Test 2. 


Test 3. 


Test 4. 


Test 5 . 


Test 6. 


POCC-to-NCC 

o Schedule requests from the POCC. 
o Ground control messages requests from the 
POCC. 

o Acknowledgements by the NCC of data flow 
receipt. 

o Performance data transmittal to the POCC. 
POCC-to-MSFC/ST SIMULATOR 

o POCC commands to the MSEC ST Simulator, 
o Receipt of simulated engineering data from 
the MSFC ST Simulator. 

POCC-to-OSCF 

o ST orbit data to the POCC. 
o TDRSS orbit data to the POCC. 
o Major planet orbit data to the POCC. 
o Solar data to the POCC. 
o Lunar orbit data to the POCC. 

POCC-to-DCF 

o Science product schedules from the POCC. 

POCC-to-ASSOCIATED CONTRACTORS 

o ST engineering data to LMSC, IBM, etc. 

o SI engineering data to Perkin Elmer, IBM, etc. 

TDRSS-to~DCF 

o Science tape recorder playback. 

0 Real-time science. 

0 NSSC-1 dumps. 

0 Status buffer readouts, 
o SI microprocessor dumps. 
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Teat 7 . 


Test 8 * 


Test 9 . 


Test 10 . 


DCF-toScIF 

o Transmission of captured science data to ST 
ScIF. 

o Transmission acknowledgement from ST ScIF. 

P 0 CC«to-TDRSS 

0 Science data. 

0 Engineering data. 

0 On-Board Computer (OBC) dumps. 

0 St commands to TDRSS. 

PASS-to-PORTS 

o Spacecraft engineering data required to 
perform sensor alignments and calibrations 
from PORTS. 

o Spacecraft engineering data for attitude 
determination from PORTS. 

0 Astrometry product generation from PORTS. 

0 Mission schedule commands from PASS. 

o OBC software updates from PASS. 

0 Maneuver verification data from PASS. 

0 Orbit data from PASS. 

POCC-to-SSC 

0 Operations and constraints data to the SSC. 

0 POCC receipt of science mission specification 
from the SSC. 

0 POCC transmission of mission schedule 
parameters and timelines to the SSC. 

o POCC transmission of science (including 
astrometry) and SI and SI C&DH engineering 
data to the SSC. 

0 Receipt of command requests from the SSC. 

0 ST status display to the SSC. 
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TABLE 3-2. PHASE II SYSTEMS ENGINEERING TEST SCENARIO 


Teat A. 


Test 5. 


Test C. 


SCHEDULING 

1 . ST operations and constraint data are 
transmitted to Science Planning and 
Scheduling System In the SSC from the POCC- 
OFLS. 

2* Science mission specifications data are 
transmitted to POCC-OFLS. 

3. POCC and NCC resolve the TDRSS Schedule. 

4. ST mission schedule la provided to the SSC 
from the POCC. 

5. POCC sends mission schedule to the NCC* 

6. NCC transmits the schedule to NASCOM, TDRSS 
and OSCF. 

7* POCC transmits a product schedule to the 
DCF. 

STORED PROGRAM COMMAND (SPC) LOADS 

1. Stored Program Command (SPC) Loads are 
uplinked from the POCC to ST via TDRSS. 

2. SPC loads are acknowledged from ST to POCC. 

3. SPC loads are uplinked to MSFC Simulator. 

4. SPC loads are acknowledged from MSCF 
Simulator to POCC* 

COMMAND REQUESTS 

1. Command requests from the SSC are transmitted 
to the POCC . 

2* Command requests transmitted from the POCC to 
the ST via TDRSS. 

3. Command requests acknowledged from the ST to 
the POCC via TDRSS. 


i|. Command requeata tranamltted from the POCC to 
the MSFC Simulator. 

5. Command requeata aoknouledged from the MSFC 
Simulator to the POCC* 

Teat D. SI ENGINEERING DATA 

1 . SI Engineering data are tranamltted from the 
ST via TDRSS to the POCC. 

2. SI Engineering data are tranamltted from the 
POCC to the SSC. 

3 * SI Engineering data are tranamltted from ST 
via TDRSS to DCF. (TBR) 

4. SI Engineering data tranamltted from the MSFC 
Simulator to the POCC. 

Teat E. ST ENGINEERING DATA 

1 . ST Engineering data tranamltted from the ST 
via TDRSS to the POCC. 

2 . ST Engineering data tranamltted from the POCC 
to the SSC. 

3. ST Engineering data tranamltted from the MSFC 
Simulator to the POCC. 

Teat F. SCIENCE DATA 

1 . Science data are tranamltted from the ST via 
TDRSS to the DCF. 

2. Science data are tranamltted from the ST via 
TDRSS to the POCC. 

3. Science data are tranamltted from the POCC to 
the SSC * 

4. Recorded aclence data are tranamltted from 
the MSFC Simulator within the POCC to the 
DCF. 
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5. Recorded data are transmitted from the MSEC 
Simulator within the POCC to the POCC. 

6* Science data are transmitted from the DCF to 
the ST SoIF. 
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Thereafter other elements would be interfaced and 
tested within and to the STOMS in a modular fashion. 
When all internal interfaces are tested, then the 
external interfaces to the SOGS would be tested* Some 
SOGS elements may not be completed time to conduct 
all STOMS/SOGS interface tests. The TAV contractor 
will develop the necessary drivers to complete the 
interface tests* 

The test scenario for Phase II indicates the dependence 
on testing a string of data or commands beginning at 
the origin. The scenario illustrated begins with the 
scheduling of the science mission from the SOGS, then 
commanding the JT, next monitoring the ST, and ends 
with the transmittal of science data to the SOGS for 
processing* 

A Phase III scenario would be a full operational 
simulation as described in detail in other 
documentation. 
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SECTION 4 


INTERFACES 

The specifications regarding each interface between major 
elements of the STOMS will be controlled by an appropriate 
ICD. In the case of the hardware and software within the 
POCC, this Interface will also be controlled through ICDs as 
they relate to the PORTS and PASS contractors. The 
responsibility for the development of each ICD will be 
assigned to a specific contractor of GSFC organization. In 
addition to the internal interfaces within STOMS, there are 
external interfaces to the SOGS and NASA institutional 
facilities . 

As indicated in Section 3, Methodology, the primary 
objective of the SOGS TAV is to verify the interface 
compatibility, both physically and operationally. Table 4-1 
presents a summary of the STOMS interfaces to be verified 
during TAF. The data categories and characteristics are 
also summarized. As noted on the Table, a number of ICDs 
are currently unavailable. Appendix I contains a list of 
the current applicable ICDs. 
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SECTION 5 


FUNCTIONAL INTERFACE REQUIREMENTS 

In th« previous sections the aajor elements to be Interfaced 
were defined. In this section the functional requirements 
for the Interfaces of these elements are delineated. These 
requirements are not presented to the level of an ICD, but 
only to the level of better definition of the TAV event 
requirements. 

5.1 POCC INTERFACE FUNCTIONAL REQUIREMENTS 

The POCC Interfaces directly with the SSC and the MPT, 
and through NGT-NASCOM to the OSCF, NCC, DCF, and MSFC 
ST Simulator. Only the SSC and NGT»NASCOM Interfaces 
are presented here. The other Interfaces are defined 
In their respective subsections. 

5.1.1 POCC AND NGT-NASCOM INTERFACE 


o Receives three telemetry data streams 
simultaneously from the NGT-NASCOM. The 
three streams are: 

o SSA channel (Hl-rate science, tape record- 
er NSSC-1 memory dumps) , 
o I channel real-time (RT) (Lo-rate science 
or engineering, DF 224 memory dump) and 
0 Q channel (RT) (Engineering DF 224 memory 
dump) . 

o Transmits commands to the ST via the 
NGT-Nascom and TDRSS. The commands will be 
transmitted In 4800 bit blocks metered to be 
consistent with spacecraft command rates of 
125 BPS or 1000 BPS. 
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5.1.2 POCC AND SSC INTERFACE 


o Permits access by the SSC to the POCC mission 
planning and scheduling data base via 
scheduled transfers. The POCC will update 
this data base with current spacecraft and 
communication constraints and operational 
data for SSC; 

o Receives science mission specifications from 
the SSC ; 

o Transmits mission schedule parameters and 
time lines from the POCC to the SSC; 
o Transmits science (including astrometry), SI 
engineering data and SI C&OH engineering data 
from the POCC to the SSC; 
o Receives SSC Command Requests (CRs). The CRs 
will be in a pre-descrlbed mnemonic format to 
change SI and astrometry Fine Guidance Sensor 
(FGS) parameters, making pointing correction 
and, where appropriate, to select among 
alternate preplanned paths in the observation 
sequence ; 

o Provides communications through control 
center lines, commercial telephone lines, and 
video lines between SSC and the POCC for 
effective control, liaison coordination, and 
data collection. 

5.2 NCC INTERFACE FUNCTIONAL REQUIREMENTS 

The NCC interfaces directly with the NGT-NASCOM, 
indirectly to the DCF, OSCF , and POCC through 
NGT-NASCOM and indirectly with the POCC through the 
MPT. 
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5.2.1 NCC AND POCC INTERFACE 


o Receives Ground Configuration Message 
Requests (GCMRs) from the POCC. These are 
requests to change the network or TDRSS 
ground support configuration; 

o Receives quality reports from the POCC; 

o Receives TDRSS service requirements via the 
MPT from the POCC; 

o Transmits TDRSS and network schedules via the 
MPT to the POCC; 

o Transmits TDRSS and network performance data 
to the POCC in the form of Operations Data 
Messages (ODMs); 

o Transmits and receives acknowledgement. 

5.2.2 NCC AND WGT-NASCOM INTERFACE 

0 Transmits GCMRs to TDRSS via NGT-NASCOM; 

o Receives TDRSS performance data from TDRSS 
via NGT-NASCOM; 

o Receives NGT-NASCOM performance data from 
NGT-NASCOM; 

0 Provides system performance data to 
NGT-NASCOM. 

5.2.3 NCC AND DCF INTERFACE 


o Transmits TDRSS schedules via TBR to the DCF. 

5.2.4 NCC AND OSCF INTERFACE 

o Receives acquisition/scheduling data 
including Predicted Site Acquisition Tables 
(PSAT), Improved Interchange Vectors (IIRVs) 
and ephemerldes from OSCF; 
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o Tranamlta TDRSS aohedulea via the MPT to the 
OSCF; 

0 Recelvea OSCF performance data from the OSCF. 

5.3 MGT-NASCOM INTERFACE FUNCTIONAL REQUIREMENTS 

The NGT-NASCOM Interfacea directly with all of the 
STOMS elementa and Indirectly to the ST through the 
TDRSS Ground Terminal. All of theae Interfacea are 
deacrlbed under their reapectlve elementa. 

5.4 TDRSS INTERFACE FUNCTIONAL REQUIREMENTS 

The TDRSS Interfacea directly with the ST and the NGT- 
NASCOM. The NGT-NASCOM Interface is presented here as 
well as a description of the Ground Spaceflight 
Tracking and Data Network (GSTDN) Interface functional 
requirements . 

5.4.1 TDRSS AND NGT-NASCOM INTERFACE 

o Recelvea GCMRa from the NGT-NASCOM; 
o Recelvea ST Command data from the NGT-NASCOM 
(See 5.1.2 POCC and NGT-NASCOM Interface); 
o Tranamlta Command data to the NGT-NASCOM (See 
5.1.2 POCC and NGT-NASCOM Interface); 
o TranamlUa ST and TDRSS tracking data (Range 
and Doppler measurements) to the NGT-NASCOM; 
o Provide equipment status messages indicating 
the equipment availability and status, to the 
NGT-NASCOM; 

o Provide performance dati. Indicating 
transmitter power, received signal strength, 
bit error rats estimates to the NGT-NASCOM. 
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5.4.2 GSTDN AND NGT-NASCOM INTERFACE 


The GSTDN will be scheduled for contingency 
support in the event of a complete TDRSS outage. 


The GSTDN does not provide science 
does : 

data 

but 

0 

Provide ST tracking data for 

the OSCF ; 

0 

Receive ST command data from the POCC 
transmits to the ST; 

and 

0 

Receive operational messages 
NGT-NASCOM; 

from 

the 

0 

Receive engineering/safe mode 

data 

tape 


recorder playback and SSM computer dump from 
the ST and transmit to the POCC and DCF. 


5.5 DCF INTERFACE FUNCTIONAL REQUIREMENTS 

0 Receives ST schedule from NCC; 

o Receives ST schedule change from the POCC; 

0 Provides voice-grade phone lines for verbal 
coordination of data capture activities with the 
POCC; 

o Provides voice-grade phone lines with the ST Scl 
transmission requests and acknowledgement; 

0 Receives real-time science data and science tape 
recorder playback data; 

o Provides a full duplex communication link with the 
ST Scl for transmission of captured science data. 

5.6 OSCF INTERFACE FUNCTIONAL REQUIREMENTS 

0 Receives ST and TDRSS tracking data from the 
NGT-NASCOM; 

0 Provides ST, TDRSS, major planet, solar, and lunar 
orbit data to the POCC; 
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o Provides acquisition scheduling data to the NCC; 
o Receives the ST and TDRSS schedule from the NCC via 
the MPT. 

5.7 ST INTERFACE FUNCTIONAL REQUIREMENTS 

o Receives, via TDRS forward link, command sequences 
or individuals commands. The rate will be 125 bps 
for the short command sequence using MA or SSA 
service. Either rate could be used for either 
purpose. 

o Receives, via TDRS forward link. Stored Program 
Command loads. The rate will be 1000 bps using SSA 
service ; 

o Transmits ST engineering, astrometry, and science 
data to TDRS on the MA and SSA channels at 4.0 or 
32, 4.0 and 1024 K bps; 

o Transmits a coherent return PM code on the MA 
channel to TDRSS for ranging purposes. 

5.8 MSFC ST SIMULATOR INTERFACE FUNCTIONAL REQUIREMENTS 

The MSCF ST Simulator control and engineering portion 
will be resident in a host computer located at MSFC. 
The POCC will provide simulator support utilizing 
software provided by MSFC to supply the simulated 
science data stream from a POCC Applications Processor 
(AP). The MSFC ST Simulator interface requirements 
are : 

o Receive output command stream from the POCC; 
o Transmits the various engineering data streams 
applicable to the ST (including astrometry). These 
data streams will represent real>time simulation of 
specific subsystems residing within the ST; 
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o Transmits 


data streams from POCC applications 
processor. In NGT-NASCOM format 4800-blt NASCOM 
blocks ; 

o Simulates . science and tape recorder data using 
predetermined Information. 
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SECTION 6 


SUPPORT ELEMENTS 

In thlfi section each of the support elements are Identified 
to the level where they can be related to the functional 
Interface requirements. 

The support elements are categorized according to: 

1. Systems and subsystems associated with each of the 
Interface functional requirements; 

2. Organizations supporting the development of test 
requirements, plans, procedures, tools and data 
bases ; 

3. Organizations supporting the test conduction, 
validation and reporting; 

4. Teat tools In the form of hardware, software and 
procedures; and 

5. Controlled Teat Data Sets. 

These five categories of support elements are discussed In 
the following five subsections. 

Matrices depicting the relationship between the support 
elements and the functional Interface requirements are 
provided In the appendices. 

Note that the Interfaces and support elements are not 
limited to those elements within the STOMS but all elements 
directly and indirectly associated with STOMS TAV. 

6.1 SUPPORT SYSTEMS AND SUBSYSTEMS 

The systems associated with the STOMS interface 
functional requirements Include the POCC, NCC, NOT- 
NASCOM, TDHSS, DCF, OSCF, ST, the MSFC ST Simulator, 
the SSC and ST ScIF. Each of these systems and 
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subsystems have been described in previous sections and 
their interfaces summarized in Section 4, Interfaces* 

The matrices depicting the system or subsystem required 
to support the test and verification of each individual 
interface functional requirement are presented in 
Appendix A. These matrices will be related to the Teat 
Sequence and Schedules in Section 7, making them a 
useful planning tool in scheduling and in the 
development of teat sce;^arios. As an example, a test 
of the POCC’s requirement to receive TDRSS and Network 
schedules would be dependent upon availability of the 
POCC, MPT, NCC and the TDRSS as indicated on the 
matrix* These dates will be used to establish a test 
date, or window, for a test sequence* 

6*2 TEST DEVELOPMENT ORGANIZATIONS 

The test development organizations are those 
responsible for developing the requirements, plans, 
procedures, tools and data bases to test the individual 
interface functional requirement* These organizations 
include both the Government and the various ST 
contractors* The NASA organizations are: MD&O (Code 

500); Flight Projects Directorate (Code 400); Networks 
Directorate (Code 800) and Project Managaement (MSFC). 
The NASA contractors are the SSM contractor, the PORTS 
contractor, and PASS contractor, the MOC contractor, 
the Scl contractor, and the SOGS contractor. The 

primary hardware and software development contractors 
for the STOMS are SSM, PORTS and PASS* The SOGS 
contractor has responsibility for the SSC and ST ScIF 
systems interfacing to the STOMS* The MOC and MD&O 
personnel share operational responsibility for the POCC 
with the MOC having primary responsibility for ST 
flight operations* The Networks Directorate has 
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operational responsibility for the NCC and NQT-NASCOM. 
The development and operational responsibility for the 
ST Simulator is part of the MSFC responslblllt:; , The 
Scl contractor will operate the SSC and ST SoIF 
interfacing the STOMS* 

The matrices Indicating the relationship between each 
Interface functional requirement and the development 
organizations are presented In Appendix B. These 
organizations are responsible for test development and 
the support of test conduction as described in Section 
10. If the organization is responsible for an ICD then 
this is also indicated. Organizations responsible for 
test conduction, validation and reporting are described 
in the next subsection. 

6.3 TEST VALIDATION ORGANIZATIONS 

The test validation organizations are those responsible 
for reviewing the test plans and procedures; conducting 
or monitoring the tost performance; coordinating the 
resolution of problems; evaluating the test results; 
and, reporting on the results. These organizations 
include both the Government and various 3T contractors 
as identified in Subsection 6.2, Test Development 
Organizations. 

The primary organizations responsible for validation 
are the operational contractors and the designated NASA 
Code. In some cases, a development organization, which 
was not responsible for the development of the 
interface being tested, could perform as a validation 
organization. As an example, the PORTS contractor 
would perform test validation on PASS developed 
software to ensure compatabllity with the PORTS 
hardware and an operational POCC. As the emphasis 
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changes from integration to validation, and then to 
training, the specific role of each contractor will 
change. The responsibilities of these organizations 
are described in Section 10. Matrices indicating the 
relationship between each interface functional 
requirement and the validation organization, are 
presented in Appendix C. 

6.4 TEST/SIMULATION TOOLS 

The test tools associated with the STOMS interface 
functional requirements Include four hardware test 
systems, a TBD number of software test packages and 
seven test scenarios. The hardware test systems are: 
o HSFC ST Simulator; 

o POCC Line Test Unit (LTO); 

o NASA Compatability Test 7an: 

o NCC Simulator. 

The software test packages are the vendor supplied 
diagnostic and demonstration packages including: 
o Operating System Exercisers; 
o Peripheral Test Packages; 
o Data Base Management Testing Programs. 

The PORTS and PASS contractors will also be developing 
software routines to provide Internal testing. The 
seven teat scenarios are those described in Section 3, 
Methodology . 

6.4.1 Hardware Teat Tools. The four hardware test 
systems are described in the following 
paragraphs . 
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MSFC ST SIMULATOR 


The MSFC ST ’’'‘mulator la the main teat and 
alfflulation tool for STOMS Implementation. A 
aummary of Ita capabllltlea and functions la 
presented here; and, a detailed deacrlptlon la 
provided In Appendix F. 

The ST Simulator, developed by MSFC, conalata 
of three oomputera - two at MSFC and one at GSFC 
with an Interface via NASCOM. (An AP In the ST 
Simulator mode will function aa the GSFC 
computer.) The ayatem aervea aa a functional 

ST, accepting and proceaalng all ST commanda and 
generating telemetry data atreama. The ST 
Simulator can produce up to three programmable 
data atreama almul taneoualy . Data atream can be 
either aoience data (pre-recorded), or 
engineering data, or both, and contain 
pre-programmed anomalies. The ST Simulator has 
the capability to respond to all St commands 
Including memory loads for the on-board 
computers . 

The functional aspects of the ST Simulator 
enable It to teat many of the telemetry and 
command interfaces within the STOMS plus the 
Interfaces to the SSC, ST ScIF and NGT-MASCOM. 

Aa the ST Simulator la a viable teat tool for 
the TAV, it la described in considerably more 
detail in Appendix F, Simulator and Teat System. 
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LINE TEST UNIT 


The POCC LTO, developed by the PORTS contractor, 
Is a programmable, operator controlled, data 
genera tor/monltcr used for fault Isolation of 
the POCC Interface. The LTU will be capable of 
simulating telemetry and command functions with 
static data as well as displaying selected data 
when received in the NASCOM format. 

The LTU's capabilities as a test tool include 
the ability to monitor telemetry and commands 
being received by, and transmitted from, the 
POCC. This provides an interface check for the 
NCC, DCF, OSCF and MPT data transmitted in 
NASCOM format. Data transmitted to and from the 
POCC using Digital Data Communication Message 
Protocol (DDCMP) can also be verified. This 
provides a check for the SSC and M3FC Simulator 
interfaces using DECnet. DECnet is a hardware 
and software interface developed by Digital 
Equipment Company. 

The LTU can simultaneously generate engineering 
and science telemetry data at selected rates. 
In a non-simul taneous mode it can play back 
DDCMP data blocks. This provides additional 
interface verification for the NCC, DCF, OSCF 
and MPT. 

The LTU is described in more detail in Appendix 
F, Simulator and Test Systems. 
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COMPATABILITY TEST VAN 


The CTV is a GSFC transportable system used to 
facilitate the oompatabllity test between the ST 
and TDRSS/NGT-NASCOM, These tests verify that 
the tracking, telemetry and command equipment 
will meet the network requirements and that the 
mission can be supported. The CTV will be 
located at the AAV contractors facility during 
the STOCC compatablllty testing. During these 
tests the CTV will not only be used to verify 
performance and adherence to network standards 
but also to verify compatablllty to the POCC and 
DCF interfaces. Using the input provided by the 
ST, the POCC and DCF can perform verification of 
their respective interfaces to the SSC and ScIF. 

More detail .>n the CTV 1s provided in Appendix 
F, Simulator and Test Systems. 

NCC SIMULATOR 

The NCC Simulator will provide simulated 
real-time Ground Control Messages (GCM's) and 
ODM*s to the POCC during training for POCC 
personnel. The NCC Simulator will be used to 
verify those Interfaces. 

6.4.2 Software Test Packages. The software packages 
associated with the LTU and ST Simulator are not 
part of this discussion. 
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In general, software test packages are developed 
to test operating systems, data base systems and 
system peripherals. Where these systems cross 
Interfaces (such as one system providing data 
base data to another) then the software package 
could become a teat tool for that Interface. 

The scripting and testing system developed by 
the PORTS and PASS contractor for system 
software testing of the POCC will provide 
Interface testing In regard to the Telemetry and 
Command (TAG) Input and Virtual Interface 
Processor (VIP) output. This will provide a 
partial teat of the NGT-NASCOM/POCC and the 
POCC/SSC Interfaces. 

Additional study of software test packages, as 
Information becomes available, may prove useful 
In this analysis. Also, the development of 
CTDSa may require development of software 
designed for the generation of specific data. 

The matrices depicting the test tools required 
to support the test and verification of each 
Individual Interface functional requirements are 
presented In Appendix D. Individual software 
test packages were not delineated since their 
primary purpose is to provide internal rather 
than Interface testing. Where the possibility 
exists that they could be used for an interface 
teat, this has been Indicated. 
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6.5 CONTROLLED TEST DATA SETS 


The CTDS'3 required to support testing of the interface 
functional requirement are identified in the matrices 
and defined in general terms in this subsection. A 
detailed description of a CTDS for each Individual 
functional requirement to be tested is a prerequisite 
for developing the test procedures. The complete CTDS 
identifies all input test material required, including 
data bases or data recorded on magnetic or other media. 
CTDS's describe drivers or stubs (dummy data or 
modules) which are required to simulate unavailable 
input data, and specify tape numbers, file names, 
and/or other means of uniquely identifying the input 
data. 

In addition to science, engineering and astrometry 
data, CTDS's include schedules, missions 
specifications, requests, orbital data, operational 
instructions or any other data essential to performing 
the test. Other information pertinent to the test data 
would also be considered part of the CTDS. This 
includes, but is not limited to, a description of the 
volume of data and the frequency at which these data 
will be required. Examples of CTDS documents are 
included in Appendix H. 

The term "Controlled" in CTDS Indicates that the test 
data identified must be under the control of the 
Configuration Manager, Test Manager or some comparable 
authority. This control assures that the test input 
will not be a variable during an incremental approach 
to testing. 
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The aatrlces depicting the CTDS's required to support 
the teat and verification for each individual interface 
functional requirement are presented in Appendix E. 
Each CTDS has been assigned a unique number for 
identification purposes. These numbers indicate (1) 
where the data originates and (2) the specific 
interfacing element involved. A correlation with the 
ST Support Instrumentation Requirements Document (SIRO) 
la also indicated. 
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SECTION 7 


TEST SEQUENCE AND SCHEDULES 

The development of a conflict free schedule for the TAV 
requires coordination of all support resources with the 
major test and simulation events competing for these 
resources. Space Telescope Observatory Management System 
Test Simulation Requirement. ISN GSFC, January 1982, 
describes in detail the support resources, the key test 
simulation events, and the tentative schedules for these 
events. This section identifies the support resources that 
must be scheduled, the key test/simulation event, and the 
TAV schedule in relation to these resource schedules and 
events . 

7.1 SUPPORT RESOURCES 

The resources required to support the STOMS TAV are the 
POCC, the DCF, the LTU, the MSFC ST Simulator, the CTV, 
and the SOGS. Those elements such as the NCC that are 
not ST unique are not Included. These multisatellite 
support elements will be scheduled as part of each 
teat/simulation event. The support resources have all 
been described in this document; however, a more 
detailed description of the MSFC ST Simulator and test 
systems is provided in Appendix F. 

7.2 TEST/SIMULATION EVENTS 

The teat and simulation activity considered as major 
events for STOMS Implementation are the VAP, the STOMS 
TAV, A&V, the SOGS I&T, the mission operations 
procedure development effort, the MOGS I&T, and 
Missions Simulation. These, as well as the training 
effort, are considered as the eight key events that 
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( 

will require sharing of the support resources and STOMS 
I elements. These events are also placed In a relative 

order of priority according to requirements for support 
, resources. Appendix G contains a summary description 

and tentative schedule of each test/slmulatlon event as 
I well as other activities concerning STOMS 

Implementation. 

I 

! 7.3 RESOORCE SCHEDULING CHARTS 

I The STOMS Implementation Study has developed Resource 

Scheduling Charts (RSCs) for each support element 
I Identified In Section 7.1. (Reference charts 7-1 

through 7-6). Each chart covers a two year period from « 

I 1983 to 1984 depicting the time element for each key ! 

event. The time element Illustrates, as a minimum, a 
; "window" for that event Indicating when the event 

begins and ends. Within this window, time Is scheduled 
for the indicated support resource. Additionally, the 
events are listed in a general order of priority as 
established by this study. The rationale for 
determining the Indicated priority was baaed primarily 
on the dependency methodology i.e., STOMS TAV and SOGS | 

I I4T must occur prior to MOGS lAT. It must be 

emphasized that this la a general order of priority. 

I As an example, although MOGS lAT has a higher priority, 

training in specific areas must occur prior to certain 
MOGS lAT events although the MOGS lAT would be the 
driving event . 

I. Within each "window" the known and probable 

requiruments for the appropriate resource are 
I scheduled. As an example, in Chart 7-1, POCC Resource 

Scheduling Chart, the known schedule for the POCC 

r - 

( during the VAP is the entire time period, or "window", 

for the VAP. This known schedule also has priority, as 
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indicated. Reference the legend on the chart. Note 
that priority schedule for the VAP, line 1, from mid 
May to the end of August 1983 has caused a scheduling 
conflict during this same period for STOMS TAV, line 3, 
and Mission Operations Procedure Development, line 7. 
Again, reference the legend. The SOGS I4T, line , 
only has a conflict for the month of August as it is 
not scheduled to begin testing until then. 

A conflict does not mean that testing or training can 
not occur during this period but that a prior schedule 
creates a conflict in scheduling that particular 
resource. As shown, the SOGS I4T would have difficulty 
scheduling the POCC, but other testing can be done 
simultaneously utilizing other resources. A similar 
situation occurs for the A4V. 

Testing during the four major A4V test periods, line 2, 
resultcj in competition for the POCC by the other events 
during this time period. Tentative schedules create a 
similar situation. As an example, the first week of 
February 1983 for the STOMS TAV, line 3» causes a 
conflict period for the Mission Operations Procedure 
Development event, line 7 . 

The priority and tentative schedules do not preclude 
the scheduling of the POCC by another event during this 
conflict period. Reference Chart 7-1 again for an 
example of this. The training window, line 8, 
indicates that during the month of December 1983 and 
the first week of January 1984 the tentative schedule 
for STOMS TAV, line 3» has priority and this is a 
conflict period for training. However, the first week 
of January has been tentatively scheduled as a training 
period coinciding with the STOMS Phase II TAV. Both of 
these events could occur simultaneously with operations 
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personnel conducting a portion of Phase II TAV 


7.U STOMS TEST AND VERIFICATION SCHEDULE 

Using the RSCs as working docuaents to determine 
resource availability and the test scenarios described 
in Section 3i a tentative schedule for the STOMS TAV 
has been developed. 

The test scenarios presented in logical test order and 
in three phases were plotted in the TAV window. The 
schedules for the supporting resource elements were 
then checked to confirm if the resource was available 
for supporting the test. If the resource was not 
available, the test was rescheduled. Plotting the 
parts of the scenario across the window of the TAV and 


checking 

the time 

the 

supporting 

resources 

were 

available 

resulted in 

the tentative 

schedule for 

the 

TAV as 

illus tra ted 

in 

Chart 7-7, 

STOMS Test 

and 


Verification Schedule. 

The STOMS TAV is divided into three phases. The first 
phase is constructed with sets of individual interface 
tests. The second phase is constructed of string 
tests. The third phase is the entire system test. 

The durations of the tests were tentatively allocated 
equal amounts of time, although this will not be the 
case in real-time testing . As each test becomes more 
definitive then the scheduling can be adjusted 
accordingly. The RSCs will enable test schedulers to 
coordinate the sharing of support resources and to 
provide teat completion in a timely manner. 
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SECTION 8 


FAILOHE REPORTING AND CORRECTION PROCEDURES 

A mechanism for systematically reporting failures and 
initiating appropriate correction action will be required 
during the STOMS TAV. The failure reporting and correction 
procedures instituted by the GSFC for use on other programs 
will be used by the TAV contractor. 

The Malfunction Report form, Figure 8-1, is a mechanism for 
failure reporting used at GSFC. (Reference GSFC 
Specifications for Contractor Malfunction Reporting. GSFC-S- 
312-P-1, March 1970 for additional information.) This form 
is used as a working document and also provides a means for 
recording information for storage and subsequent retrieval. 
The corresponding form to be designed for use during the 
STOMS TAV should provide the entry of similar information 
relevant to failures encountered during testing. 
Specifically, the malfunction report form should provide, as 
a minimum, designated spaces for the following information 
to be recorded: 

1. Date and time of malfunction. 

2. Date the malfunction report was originated. 

3. Identification of the failed test item. A failed 
hardware item should be specified by level (e.g., 
system, subsystem, component), and the manufacturer's 
name and identification numbers (e.g., manufacturer's 
part number, item serial number) should be provided. A 
failed software item should also be specified by level 
(e.g., system, subsystem, module), and the software 
developer's name and appropriate identification numbers 
should be provided. 

4. The type of test that was being conducted when the 
malfunction occurred (e.g., OSCF/POCC orbit data 
interface test). 
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5. Specification of the actual environment that the test 
unit was being subjected to when the malfunction 
occurred . 

6. All details of the malfunction such as inputs, outputs, 
tolerances, etc. 

7. A detailed, concise narrative defining the direct cause 
of the malfunction. 

8. A detailed, concise narrative specifying the corrective 
action taken. Including a list of other hardware or 
software units affected by the corrective action. 

9. Indication of whether a failure analysis was conducted. 
If affirmative, specify the organization which 
conducted the analysis, and give the number and date of 
the corresponding report prepared. 

10. Indication of rework of a failed item, identifying the 
organization that performed the rework and its 
completion date. 

11. Indication of, and restrictions on, the future use of a 
reworked item. 

12. Indication of whether the retest of a failed item is 
required. If retest is required, state the test 
requirements . 

13 . Indication of the results of any retest. 

14. Approval signatures certifying completion of corrective 
actions taken. 

The initiation of corrective procedures during the STOMS TAV 
may be modeled after other QSFC corresponding systems. 
Corrective procedures are initiated at the request of the 
equipment operator, or in the absence of the operator, by 
the individual identifying the malfunction. The equipment 
operator notified the shift supervisor of the malfunction 
who, in turn, notifies the maintenance staff. The shift 
supervisor initiates the malfunction report, indicating the 
time of failure and the symptoms observed. 
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If the malfunction la not corrected within a specified mean 
time to repair (time would be dependent upon system), then a 
Corrective Maintenance Work Plan, (Figure 8-2) to undertake 
necessary corrective action will be required. This work 
plan is to be prepared by the responsible maintenance staff, 
subject to approval by NASA. The operation supervisor will 
be responsible for ensuring that preparation of the work 
plan is accomplished. The primary purpose of the work plan 
1s to ensure an organized, controlled, and coordinated 
approach to troubleshooting a problem that may encompass 
several disciplines, development contractors, maintenance 
contractors, operation personnel and NASA. 

After a malfunction is corrected, the malfunction report is 
completed by the responsible engineer or technician, and 
signed by him and the shift supervisor. The shift 
supervisor will determine if a line test is required, and 
will notify affected parties of the system status. 

The equipment operator is responsible for logging the time 
reqired for malfunction, correction time and the malfunction 
report numbers into tne Equipment Operator's Log and into 
the Malfunction Report Log. 
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CORRECTIVE MAINTENANCE WORK PLAN 
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SECTION 9 


TEST PLANS AND PROCEDURES 

Descriptions of the numerous tests which are required during 
the two phases of the STOMS TAV were presented in Section 3. 
In order to achieve maximum effectiveness in their 
performance, each of the required tests must be conducted in 
accordance with an established test plan. A teat plan may 
consist of a group of individual testa designed to assure 
verification of a particular system or subsystem, or it may 
be comprised of a sequence of tests required to validate a 
particular function. Reference Figure 3-1, STOMS 
Requirementa/Tea t Procedure Interrelationships. 

Each test to be conducted should follow a detailed 
procedure. The teat procedures will be prepared by the 
development contractor or TAV contractor, as appropriate, 
and will be approved by NASA. This section provides 
outlines of the formats applicable to the preparation of 
teat plana and procedures. Uniform test plans and 
procedures from each contractor will expedite review of such 
plana and aid in maintaining traceability of teat 
procedures . 

9.1 TEST PLAN OUTLINE 

An outline of the format to be used for the preparation 
of teat plana, and description of the contents of each 
section, are provided below in the following pages. 
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TEST PLAN OUTLINE 


A. TEST PLAN DESCRIPTION 

1 . Objectives 


The functions 

of 

the 

interface/ elements 

are 

summarized 

and 

the 

objectives of the 

tests 

are 

defined in 

this 

sec 

tion 

. This section 

will 

also 

Include a 

summary 

of 

the specific project. 

the 

organizations involved, 

the location of 

the 

test , 


and reference to any prior testing. 

2. Description 

Each te>it included in this plan, will be described 
in detail and the individual test procedures 
referenced . 

3. Environment 

The test personnel, documentation, hardware, 
software interfaces, physical location, inputs, test 
materials, data handling support, data bases, and 
all other support material and/or services required 
to perform each test are identified in this section. 

4. Requirements To Be Verified 

The requirements to be verified by each test are 
specified in this section. The requirements 
specified should correlate with the Integration Test 
Plan and the most recent design review or other 
relevant documentation. The hardware and software 
functions to be exercised are listed in this section 
in relation to the test identified. 
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B. EVALUATION PLAN 


The measuremente to bo taken and the method to 
record the teat results during each teat are 
specified in this section. Other pertinent 
Information about the tests, such as the expected 
results, are provided. 

The pass/fail acceptance criteria and any 
limitations due to the teat environment are 
specified in this section. 

The teat evaluation techniques, methods of 
measurement, equipment, personnel, reporting, and 
any additional unique requirements are also 
described, with references being made to specific 
test plans. 

C. TEST TEAM MEMBERS 

The functions of each member of the test team are 
described in this section, and the organizational 
affiliation of each team member indicated. This 
section specifies training required by each 
operation and test team member. The procedures for 
assuring the qualification of these personnel to 
conduct the required tests are also described. 

D. SCHEDULE 

The sequence of the tests included in tht plan are 
described in this section, and the rationale for the 
sequence established provided. The schedule for 
performing these tests, based upon known 
prerequisites of other deliverables or upon any 
other prevailing constraints, are also indicated. 
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E 


ANOMALY PROCEDURES 


The procedures to be invoked in the event of 
contingencies are specified in this section. If 
applicable, alternate sequences to be followed in 
the test progression in the event the occurrence of 
unexpected anomalies are described. As appropriate, 
reference is made to other applicable procedures. 

F. CONFIGURATION MANAGEMENT 

The Configuration Management Plan will be described 
or referenced in this section. Procedures for 
partial retesting while maintaining configuration 
control will be defined. 

G. DEBRIEFING 

The particular format for reporting on the test 
results will be defined in this section. This would 
include the form of written, verbal or visual 
presentation, method of managing action items, 
attendance, plus schedules for debriefing, followup 
and other actions. 
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9.2 TEST PROCEDURE OUTLINE 


An outline of the format to be used for the preparation 
of test procedures and description of the contents of 
each section, are provided in the following pages. 
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TEST PROCEDURE OUTLINE 


A. TEST SEQUENCE 

The steps necessary to accomplish each test will be 
specified in this section in the precise sequential 
order in which they are to be conducted. The 
specified steps include: receiving the test 

article; reviewing ail applicable documentation; 
providing orientation to test tsam members; 
gathering required test support materials; 
scheduj. ing required test support services; 
perform.ng the individual tests, analyzing and 
reporting the results of each test; and, acceptance 
of the test article. The individual steps invo3ved 
in the performance of eacn test will be listed in 
this section. 

B. CONTROLLED TEST DATA SET 

All CTDS required to support each t-st ar<^ specified 
in this section. This specification defines all 
test materials required, identifies access which is 
required to specific data bases, and defines all 
drivers or stubs which are required to simulate 
unavailable components. These input requirements 
specify tape numbers, file names, or other means of 
uniquely identifying the supporting data required. 
The volume of input data and the frequency at which 
these data will be required are specified to the 
extent feasible. 
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C. CONFIGURATION 

The hardware and software configuration required for 
the performance of each teat (e.g., number of tape 
drives and operating system) are specified in this 
sec tion. 

D. REPORTING FORMAT 

The particular formats to be used for reporting 
problems, specifying test results, and summarizing 
the execution of each teat are indicated in this 
section. 

E. OUTPUT 

The output products required in connection with each 
test are fully described in this section. The 
labeling, routing, and storage requirements of all 
hard copy, magnetic media, and other output products 
are indicated. The requirements for recording video 
messages or other data are also specified in this 
section. When the output product is to become part 
of a CTDS then the procedures required to control 
this data will be referenced or included. 
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SECTION 10 


TEST ORGANIZATION 

The TAV contractor will have full responsibility for the 
development, conduction, and completion of the TAV 
activities; however, specific functions within the TAV will 
be the responsibility of individual GSFC or contractor 
•organizations. This assignment of responsibility and 
composition of teat groups is depicted in Figure 10-1, STOMS 
Test and Verification Organization. The TAV program aspects 
will consist of test development, test conduction, test 
support and test reporting as illustrated in the organiz- 
ation chart. 

10.1 TEST MANAGER 

The teat manager has overall responsibilities for the 
test groups. These responsibilities include, but are 
not necessarily limited to: reviewing test plans and 

procedures; coordinating the activities of contractors; 
monitoring the performance of tests; coordinating the 
resolution of problems; analyzing test results; and 
preparing and reviewing test reports. 

10.2 TEST DEVELOPMENT GROUP 

The Teat Development Group is headed by the TAV 
contractor who h general responsibilities for 
developing all tea plans and procedures. Procedures 
previously developed by the development contractor will 
be used where applicable. The same organization that 
has developed and maintained the ICD related to each 
interface will be responsible for the preparation of 
the teat requirements, plana, procedures, and test 
report for each Phase I teat. T: 3 other interfacing 
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entity will review these documents for accuracy and 
completeness, and will provide inputs related to its 
unique responsibilities, as required. The MOC will 
prepare Phase II test requirements, plans, procedures 
and reports as required. The TAV contractor will 
coordinate their effort and develop those items not 
under the responsibility of another contractor or GSFC 
directorate. All teat documents will be approved and 
controlled by the GSFC. 

10.3 test conduction group 

Each development contractor organization involved in a 
Phase I test will supply the test and operations 
personnel required to support the test. 

Phase II tests will be performed by operations 
personnel provided by the Mission Operations 
contractor. During both phases, NASA MiO personnel 
will be responsible for the operations of the NASA 
facilities. 

TAV contractor personnel will be responsible for 
coordinating all test conduction efforts including the 
scheduling of activities, monitoring the performance of 
the tests and ensuring configuration control. 

Configuration control will be exercised in accordance 
with contractor-developed, and NAS A -approved, 
Configuration Management Plans. Each such plan shall 
meet the requirements of the GSFC Space Telescope 
Project Configuration Management Plan, GSFC-ST-CMP, 
Revision A. Space Telescope (ST) Scientific Instruments 
and Mission Operations Configuration Management Plan, 
February 1980. All Class One changes to the 
configuration baselines shall be approved by NASA, and 
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shall be 
con trac tors . 
functional 
performed in 


properly documented by th 
This document also describes 
and physical audits which 
connection with configuration 


e cognizant 
the specific 
are to be 
control . 


The ST Project will maintain configuration control over 
the various STOMS-to-SOGS interfaces as well as the 
STOMS to NASA facility interfaces. The participating 
ground system and TAV contractors will appoint repre- 
sentatives as required to provide representation at the 
board controlling these interfaces. 


The TAV contractor shall review and analyze the 
following functions both during and after the execution 
of each teat: volume of input data ingested; volume of 

data having conversions properly performed; output data 
volume; proper handling of anomalies; system throughput 
capabilities; and out-of-limits function execution 
times . 

10.4 TEST SUPPORT GROUP 

Prior to testing, the development contractors will 
provide the TAV contractor and MOC with such technical 
support as is required to ensure that the training of 
all teat personnel is phased to adequately support 
their roles in the TAV. 

During testing, the Test Support Group will provide 
maintenance, operational and management support as 
required. The TAV contractor will be responsible for 
coordinating this activity. 
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10.5 TEST EVALUATION GROUP 


Tlie Test Evaluation Group will report in detail on each 
test conducted; determine the need for additional 
testing to correct deficiencies; recommend contractual 
acceptance of tested elements; and, make recommend- 
ations for system implementation. The group will 
provide reports containing the comparison of the 
recorded test measurements, or results, with those 
results which are anticipated or specified in the test 
plan. Any requirements which were not verified will be 
identified, and the probable cause of the failure to 
verify a requirement will be cited in each instance. 

Specific recommendations regarding the measures 
necessary to correct any failures or limitations 
encountered during testing will be provided in their 
report. These recommendations will include estimates 
of the expenditure of time and resources required to 
implement the suggestions. The test evaluation report 
will include recommendations regarding the readiness 
for implementation of each element tested. 
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APPENDIX A 

REQUIREMENT/SUPPORT SYSTEMS MATRICES 


The following matrices depict the relationship be- 
tween the STOMS interface functional requirements (along the 
top of the page) and the support systems (along the side of 
the page). The interfacing elements are numbered 1 through 
9 and correspond to the support systems. The MPT for the 
purposes of this matrix is considered part of the NCC (2); 
and, the ST ScIF and SSC are both part of the SOGS (9). 

As an aid in reading these matrices, the 'from' and 
'to' can be read into each interface description. As an 
example, the first three pages illustrate the POCC inter- 
faces grouped according to the element being interfaced. 
The first group of interface functional requirements are 
those that pertain to the POCC and the NCC. The first 
interface requirement within this block is 'TRANSMITS 
GCMRS'. This is read as "the POCC transmitts GCMRs to the 
NCC". The systems required to support this interface test 
are (those asterisked) the POCC, NCC and NGT-NASCOM. 

The 'AVAIL DATE' indicates the date the support system 
is to be available for integration. The 'TEST DATE' will be 
the earliest date that the system is required for testing 
the interfaces indicated. These dates will be completed as 
data becomes available. 
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APPENDIX B 


REQUIREMENTS/TEST DEVELOPMENT ORGANIZATIONS MATRICES 

The following matrices depict the relationship be- 
tween the STOMS interface functional requirements (along the 
top of the page) and the test development organization 
(along the side of the page). The interfacing elements are 
numbered 1 through 9 and correspond to the support systems 
( see Appendix A) . The MPT for the purposes of this matrix 
is considered part of the NCC (2); and, the ST ScIF and SSC 
are both part of the SOGS ( 9 ) . 

As an aid in reading these matrices, the 'from* and 
'to' can be read into each interface description. As an 
example, the first three pages illustrate the POCC inter- 
faces grouped according to the element being interfaced. 
The first group of interface functional requirements are 
those that pertain to the POCC and the NCC. The first 
interface requirement within this blocic is 'TRANSMITS 
GCMRS'. This is read as "the POCC transmits GCMRs to the 
NCC" . The test development organization to support this 
interface test is the PORTS contractor. 
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The following matrices depict the relationship be- 
tween the STOMS interface functional requirements (along the 
top of the page) and the test validation organization 
(along the side of the page). The interfacing elements are 
numbered 1 through 9 and correspond to the support systems 
(see Appendix A). The MPT for the purposes of this matrix 
is considered part of the NCC (2); and, the ST ScIF and SSC 
are both part of the SOGS ( 9 ) . 

As an aid in reading these matrices, the 'from' and 
'to' can be read into each interface description. As an 
example, the first three pages illustrate the POCC inter- 
faces grouped according to the element being interfaced. 
The first group of interface functional requirements are 
those that pertain to the POCC and the NCC. The first 
interface requirement within this blocic is 'TRANSMITS 
GCMRS'. This is read as "the POCC transmits GCMRs to the 
NCC". The test validation organization to support this 
interface test are (those asterisJced) the MOC, M&DO, and 
Networ)cs. 
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The following matrices depict the relationship be- 
tween the STOMS interface functional requirements (along the 
top of the page) and the test tools (along the side of the 
page). The interfacing elements are numbered 1 through 9 
and correspond to the support systems (see Appendix A). The 
MPT for the purposes of this matrix is considered part of 
the NCC (2); and, the ST SciF and SSC are both part of the 
SOGS (9). 

As an aid in reading these matrices, the 'from' and 
'to' can be read into each interface description. As an 
example, the first three pages illustrate the POCC inter- 
faces grouped according to the element being interfaced. 
The first group of interface functional requirements are 
those that pertain to the POCC and the NCC. The first 
interface requirement within this block is 'TRANSMITS 
GCMRS'. This is read as "the POCC transmits GCMRs to the 
NCC". The test tools required to support this interface 
test are (those asterisked) the LTU, NCCS Simulator, vendor 
software, TAV, and mission simulation. 
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The following matrices depict the relationship be- 
tween the STOMS interface functional requirements (along the 
top of the page) and the test CTDSs (along the side of the 
page). The interfacing elements are numbered 1 through 9 
and correspond to the support systems (see Appendix A). The 
MPT for the purposes of this matrix is considered part of 
the NCC (2); and, the ST Self and SSC are both part of the 
SOGS (9). 

As an aid in reading these matrices, the 'from' and 
'to* can be read into each interface description. As an 
example, the first three pages illustrate the POCC inter- 
faces grouped according to the element being interfaced. 
The first group of interface functional requirements are 
those that pertain to the POCC and the NCC. The first 
interface requirement within this block is 'TRANSMITS 
GGMRS'. This is read as "the POCC transmits GCMRs to the 
NCC" . The CTDS required to support this interface 
is the GCMR CTDS. 

A control number (CTDS NO.) for each Control Test 
Data Set uniquely identifies that data set plus indicates 
the particular system element and interface. The following 
list indicates the code used for labeling the CTDS. The 
alpha character indicates the system originating the data 
(the 'from* element). The numeric code indicates where this 
data terminates (the 'to' element). 
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As an example f CTDS; nuiaber Nl4/ would indicate that 
this CTDS (Performance Data) originates in the NCC (N), 
terminates with the POCC (1)/ and is number 4 in that 
series. 

Where applicable the Support Instrumentation Require- 
ments Document (SIRD) number has also been indicated. 
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APPENDIX F 


ST SIMULATOR AND TEST SYSTEMS 

This appendix provides more detail on the MSEC ST 
Simulator# the LTU and CTV as introduced in Section 2# 
Support Elements. 

Several documents used as source material for the 
preparation of this report and are listed in the Biblio- 
graphy. Some portions of these source documents have been 
included in the Appendices for reference purposes. 

1 . MSFC ST SIMULATOR 

An overview of the ST Simulator is shown in Figure -1# 
ST Simulator Configuration. The primary elements# which 
simulate engineering data and respond to received command 
data are located at MSFC. The elements which are located in 
the STOCC at GSFC are used primarily to insert pre-recorded 
science data into the telemetry data stream and feed it to 
the POCC TAC subsystem. The computer used at GSFC is the 
VAX 11/780 which functions as the on-line system backup and 
simulator support. 

The two basic applications for which the ST Simulator 
is intended are verification and personnel training. These 
applications are defined in the following paragraphs fol- 
lowed by a detailed description of the ST Simulator inter- 
face# functions# and applications. 

1.1 VERIFICATION 

The ST Simulator will verify the ability of the 
STOMS systems to perform their online and offline functions 
in accordance with design requirements. The ST Simulator 
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FIGURE F-1 ST SIMULATOR CONFIGURATION 









serves as a functional Space Telescope interfacing with 
NASCOM, and exhibits the same data Interface to the STOMS as 
the ST itself. It serves as an engineering and science data 
source to fully exercise the operation's ground system to 
help validate the system's ability to process ST data. The 
ST Simulator accepts and processes all valid ST commands, 
reflecting command effects in telemetry to validate the 
ground control capability over the "T. A detailed descrip- 
tion of the STOCC functions to be v'erified is presented in 
the .following subsections and Appendix H. 

The simulator may be used to produce up to three 
telemetry data streams simultaneously. it is programmable 
to all ST data rates and formats. Data ancunolies, such as 
dropouts and noise, may be either operator induced or 
pre-programmed. The data may represent engineering data 
which is generated within the St Simulator or science data 
which has been pre-recorded. Also, both science and engine- 
ering data streams may be output simultaneously. The 
engineering data stream will be altered by the software 
models. 

The software models developed for the ST Simulator 

are: 

• Systems Support Module (SSM) subsystems; 

• Science instruments (SI); 

• Optical Telescope Assembly (OTA) components; 

• Science Instrument Control and Data Handling (SI 

C&DH) subsystems. 

The response of these models may be effected by the receipt 
of ST commands, the simulation of environmental stimuli, or 
the generation of On Board Computer (OBC) commands. The 
characteristics of sensor misalignments, drift, and null 
offsets may be exhibited by attitude sensor models, and 



these characteristics may be altered by an operators input. 
All modes of the Safing System are modeled including initia- 
tion by operator or conditions which would normally result 
in entry into such modes in the ST itself. The return to 
normal operations from safing modes is brought about by the 
receipt of applicable commands. 

The ST Simulator has the capability to detect and 
respond to all valid ST commands. It will detect and reject 
invalid commands. It receives and responds to commands to 
the OF224 and NSSC-1 computers including memory load?. 
Delayed mode commands are stored and executed at the proper 
time and are time tagged accordingly. 

1.2 PERSONNEL TRAINING 

The ST Simulator provides the facility to train opera- 
tions personnel in the conduct of Orbital Verification and 
normal Mission Operations. using this training tool , 
operations personnel will verify operations procedures and 
proficiency for both spacecraft and science activities under 
both nominal and exception conditions. This training 
activity will involve the following; 

a. validation of the launch script through simula- 
tions; 

b. validation of the orbital verification script 
through simulations; 

c. Validation of normal mission control through 
simulations; 

d. validation of preplanned recovery procedures from 
abnormal conditions including safing entry » loss of 
attitude control, etc.; 


e. Certification of operator control position assign- 
ments. 

The ST Simulator will realistically portray nominal 
operations^ including observatory on-orbit activation and 
verification, as well as a limited number of specific 
off-nominal conditions. 

The command responses and other data generated by 
the ST Simulator are of sufficient realism to provide 
positive training in all on-line and critical off-line 
operations functions. The ST Simulator is also capable of 
being configured to match specific planned orbital condi- 
tions, systems configurations, and event sequences specified 
by STOMS personnel. 

The ST Simulator supports simulations of limited 
duration to train in specific operations tasks, as well as 
all-up mission simulations with a possible duration of 
several days. 

1.3 ST SIMULATOR INTERFACES 

The engineering telemetry and command interface be- 
tween the St Simulator and the STOCC is through NASCOM. On 
the STOCC end, the interface with NASCOM is the TAC. At the 
ST Simulator end the NASCOM interface is the Command and 
Telemetry processor. An additional interface exists between 
the ST Simulator and STOCC for communication of instructions 
and information between the computers at each location. The 
high rate science telemetry data interface with the ST 
Simulator is accomplished via the Simulator Support VAX at 
Goddard and the TAC using a NASCOM simplex link. The 
characteristics of the interfaces mentioned above are given 
in the following paragraphs. 



Telemetry and Coirnnand interface 

Tne ST Simulator generates ST engineering telemetry 
data in all formats and at all rates. This data is format- 
ted into 4800 bit NASCOM blocks and transmitted to the STOCC 
over a 56 Kb/s full duplex NASCOM link. Data rates trans- 
mitted are 32 Kb/s, 4 Kb/s or 0.5 Kb/ps. The rate and 
format of engineering data generation are selectable by 
STOCC command, automatic safe mode initiation or ST Simula- 
tor operator control. 

Command interface 

Command messages are generated in the STOCC and trans- 
mitted to the ST Simulator at data rates of 1.0 Kb/s or 125 
b/s via the 56 Kb/s duplex NASCOM link. Command messages 
are transmitted in NASCOM 4800 bit blocks, received and 
decoded into 48 bit command words in the ST Simulator. 

Science Data interface 

The ST Simulator does not generate science data. 
The science data interface is established through playback 
of pre-recorded science data by the Simulator Support VAX 
located at GSFC. The data is encoded and packet ized at a 
4.0 Kb/s or 1024 Kb/s rate and transmitted to the TAC in 
4800 bit blocks, via NASCOM simplex low or high rate data 
link and the PORTS high rate switch. Control of the data 
formatting and transmission is via ST command or ST Simula- 
tor operator actions. The science data stream may be 
optionally Reed-Solomon (RS) or psuedo-noise (PN) encoded. 
Another option is che transmission of spacecraft computer 
memory dump information. The low data rate link may be used 
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by SSM computers (DF-224) memory dump data* The high data 
rate link may be used for SI C&DH computer (NSSC-1) memory 
dump data. 


Control DECNet Interface 

The transfer of control instructions and information 
between the Simulator Support VAX 11/780 computer at GSFC 
and the computers in the ST Simulator at MSFC utilizes a 
full duplex 56 Kb/s NASCOM link. The communications network 
is supported by DECNet. 

voice Interface 

There will be four voice links between STOCC and 
MSFC available for use during the testing activities of the 
ST. 


1.4 SIMULATOR FUNCTIONS 

The functional breakdown of the ST Simulator is shown 
in Figure F-2f ST Simulator Functional Breakdown Structure. 
A discussion of the functions of the major elements is given 
in the following paragraphs. 


Simulator Control 

The simulations will require a simulation director/ 
team. This teaun will asserable/enter initialization data, 
monitor the performance of the simulation, change ST Simula- 
tor control values during simulations, capture required data 
and otherwise interact with the ST Simulator as the simula- 
tion progresses. 
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FIGURE F*2 ST SIMULATOR FUNCTIONAL BREAKDOWN STRUCTURE 







Support Systems Module 

The S3M consists of the pointing Control Subsystem, 
the Electrical power Subsystem, the instrumentation and 
Communication Subsystem, the Data Management Subsystem, the 
Thermal Control Subsystem, the Safing System, and Structures 
and Mechanical Subsystem under control of the DF 224 com- 
puter. Each of these may be functionally modeled in the ST 
Simulator. 


Optical Telescope Assembly 

The OTA is a 2.4m f24 Cassegrain telescope consis- 
ting of two elements, a primary and secondary mirror. The 
focal plane of the telescope is divided among eleven sensing 
devices: four axial and one radial scientific instruments, 
three optical Control Sensors, and three Fine Guidance 
Sensors. Other components include an Actuator Control 
Subsystem, Elecrical power Subsystem, and Thermal Control 
Subsystem. 

Each of these will be functionally modeled in the 
ST Simulator to meet requirements to support the STOCC 
verification and personnel training. 

Scientific instruments Control and Data Handling 

The SI C&DB provides a unified command, data and 
telemetry interface between the five scientific instruments 
and Uie SSM Data Management System. 

The SI C&DH system consists of three basic components, 
the Control Unit/Science Data Formatter (CU/SDF), Standard 
Interface for Computer (STINT) and NASA Standard Spacecraft 
Computer, Model 1 (NSSC-1). 
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The ST Simulator is designed to model; the CU/SDF 
control logic for science data stream output, using standard 
header data, unique logs, status buffer, and canned SI data 
as data sources; the CU/SDF capability for programmable 
science formats; and, the CU/SDF capability for receiving, 
decoding, storing and properly executing commands. 

Science Instruments 

There are five science instruments on the ST. These 
are; Faint object Camera, Faint Object Spectograph, High 
Resolution Spectograph, High Speed photometer, and the Wide 
Field/Planetary Camera. 

The ST Simulator will not simulate science data. 
The St Simulator functions are to; accept commands from the 
SI C&DH and respond through the SI engineering data; provide 
the capability to feed pre-recorded science data through the 
science data stream for each instrument; provide capability 
to accept data loads to the SI microprocessors and OBCs; and 
provide the capability to dump maps of the SI microprocessor 
and OBC memories. 

1.5 SIMULATOR APPLICATION 

The capabilities of the ST Simulator which are nec- 
essary to support test activities may be developed in stages 
based upon the planned test activities. The following 
paragraphs describe the use of the St Simulator during these 
events. 


verification and Acceptance program 

The ST Simulator must initially support verification 
of the PORTS hardware and software capabilities. The 
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ST Simulator will accept and process SI and SI~C&DH real 
time and stored commands; generate SI and SI C&DH engine- 
ering data which has reasonable values for STOCC processing 
and is properly formatted; simulate the SSM DMS system to 
the extent necessary to flow SI data; support a 4 Kb/s rate 
science engineering telemetry format; support a science data 
stream of predefined fixed content; and, support SI C&DH 
memory load and dump. 

Assembly and verification 

During the A&V tests all STOCC interfaces with the 
ST will be compatiblity tested using the NASCOM facilities 
for communications. There will also be a mission simulation 
conducted. The ST Simulator must be available with full 
data and command processing capability to verify the STOCC 
capabilities prior to STOCC participation in these tests. 

STOMS Test and verification 

The ST Simulator will be a primary tool in the com- 
pletion of TAV activities. The completion of verification 
activities prior to VAP and A&V constitute a part of the TAV 
but there are additional interfaces and functions within the 
STOMS which will be tested by use of the ST Simulator. The 
operations between PORTS, PASS and the DCF must be tested. 
The ST Simulator may be used as the source of data in any 
tests which include an exchange of data and or commands. 
This description fits many TAV activities including those in 
Phase I, Interface Test. 

2. LINE TEST UNIT 

An overview of the LTU is shown in Figure F-3, Line 
Test unit. The primary elements are a Test Data Monitor, 
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Test Data Generator » Test Controller and Data operations 
Control all within one unit located at the POCC. Its 
primary purpose will be to function as a hardware checkout 
tool by monitoring data sources, generating test data and 
simulating specific ST command/telemetry interactions. 

The Test Data Monitor will allow the extraction of 
selected data for display. Certain parameters can be 
selected to validate the header when NASCOM' format is 
used. 

The Test Data Generator portion of the LTD will per- 
mit the insertion of known data patterns selected from 
predefined formats into a serial communication interface. 

The Data Operations Control and Test Controller pro- 
vide the control, display and self testing functions of the 
LTU. 


2.1 MONITORING 


Monitoring Data Sources 

The LTU will be capable of monitoring external data 

lines to and from PORTS. The monitored data sources are as 
follows: 

• NASCOM telemetry on a 56 Kb/s or 1.544 Mb/s, 

line; 

• TAC B channel command output on a 56 Kb/s, NASCOM 
format line; 

• TAC B channel SSC output on a 1.544 Mb/s line, 
NASCOM-like blocks; 

• AP DDCMP Channel output to, or input from, the SSC 
on a 56 Kb/s line; 

• AP NASCOM channel output and input for NCC, DCF, 

OSCF, and MPT interfaces; 

• AP DDCMP channel output or input from MSFC ST 

Simulator control line on a 56 Kb/s line. 
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Monitoring Functions 


The monitoring functions of the LTU consist of dis- 
playing, collecting statistics and recording data blocks. 
The formatted display in hexadecimal of the contents of data 
blocks or block header are as follows: 

• NASCOM telemetry and command blocks; 

• TAC data blocks output to SSC; 

• DDCMP blocks transmitted or received; 

• PORTS AP NASCOM blocks transmitted or received. 

The collection of statistics on data blocks are as 
follows: 

• Number of blocks; 

• Number of blocks with poly errors; 

• Number of block sequences errors as applicable; 

• Number of blocks with selected header fields in 
error; 

• Number of command words in command blocks. 

The collection of statistics on spacecraft telemetry 
synchronization status are as follows: 

• Number of sync search operations; 

• Number of bit-slipped frames; 

• Number of frames without frame sync error; 

• Number of drop lock occurrences; 

• Number of frames with errors in synchronization 
pattern. 

The recording of incoming NASCOM blocks and DDCMp blocks 
(not concurrent with NASCOM blocks) on a magnetic tape from 
a single incoming line are also part of the monitoring 
functions of the LTU* 


2 . 2 DATA GENERATION 


The three simultaneous telemetry test streams that 
can be generated by the LTU are as follows: 

• Engineering telemetry at 0.5» 4» or 32 Kb/s; 

• DF-244 dump or science telemetry stream at 4 
Kb/s; 

• Science telemetry or tape recorder playback at 1024 
Kb/s, except that science shall not be concurrently 
output at both 4 and 1024 Kb/s. 

The LTU will additionally generate the following; 

• Playback of DDCMP blocks at a line rate of 56 Kb/s 
for the online system or offline system message 
transfer in either direction; 

• NASCOM AP test traffic for DCF, NCC, OSCF, or MPT 
message traffic in either direction. 

2.3 TELEMETRY GENERATION 

The LTU telemetry generation is divided into static 
and dynamic telemetry functions. 

Static Telemetry 

The LTU static te’eraetry generation will be divided 
in four parts. The generation of static engineering tele- 
metry will provide; 

• Generation of predefined and fixed sync patterns; 

• Incrementation of frame counters; 

• Generation of data formats by simple algorithms; 

• Predefined and repeated faulting of parameters. 

The generation of static science telemetry will provide: 

• 1024-bits/segment with segments packetized and 
having a fixed sync pattern; 

• Incrementation of packet count and segment numbers; 
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• valid combination of Rs segments and PN encoding; 

• Insertion of source ID and Packet Format Code. 

The static telemetry generation will provide for generation 
of DF-224 dump data; and also Engineering Tape Recorder 
(ETR) and Science Tape Recorder (STR) dump data at 1 Mb/s 
with bit to byte expansion and data reversal. 

Dynamic Telemetry 

The dynamic telemetry generation function is as fol- 
lows; 

• Dynamic responses to interpretations of commands 
such as command counter incrementation and setting 
checksum flags; 

• Dynamic update of command verification bi-levels in 
telemetry due to interpretation of commands; 

• OBC memory maps maintained based on load received; 

• variable faulting at operator's request. 

3. COMPATABILITY TEST VAN 

The Multimission Unique Ground Support Equipment 
(MUGSE) / Figure 3-4 » is the planned CTV system for the TDRSS 
mode of operation. The MUGSE system includes a KU- and 
S-band relay, s-band Transponder Test Set (STTS), s-band 
Spread Spectrum Transponder (SSST), and peripheral equipment 
consisting of ranging, command, and data handling sub- 
systems. The MUGSE system will be capable of the following: 

• Act as a RF relay; 

• Act as a test set for fault isolation; 

• Act as ST Simulator to verify the integrity of the 
RF link; 

• Communicate with the ST; 

• Provide self testing of STTS; 
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• Coronunicate with TDRSS to emulate the ST under 
test; 

• Act as an independent test bed for ST verification; 

• Provide the capability for telemetry spread spec- 
trum demodulation; 

• Allow for data flows between the ST at manufac- 
turer's site during A&V and the POCC NCC. 


3.1 RELAY MODE 

In the relay mode the van will serve as a throughput 
amplification system to interface the St communication 
systems via TDRSS and ground system. The CTV relays forward 
commands and ranging signals from TDRSS to the Satellite 
Under Test (SUT)» in this case the ST# and the return 
telemetry from the ST to TDRSS. The typical interface 
between the CTV and satellite is via a coaxal cable. 
Reference Figure 3-5 » TDRSS Compatability Test Configura- 
tion. 


3.2 S-BAND TRANSPONDER TEST SET 

The STTS consists of five major assemblies: test 
transmitter, test receiver, RF distribution, ranging sub- 
systems, and command source/bit error test. Figure 3-6/ 
S-band Transponder Test Set, is a functional block diagram 
of the system. The RF chassis assemblies generate the 
forward link (FT) in the 2025- to 2120-MHz frequency range, 
in the TDRSS mode, Quadriphase- Shift-Keying (QPSK) modula- 
tion by selectable PN codes clocked at 31/96 (FT/221) is 
provided. The return link signal is in the 2200 to 2300 MHz 
frequency range. The demodulation of the (3PSK return link 
consisting of the in-phase (l-channel) and the quadriphase 
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FIGURE F-5 TDRSS COMPATABILITY TEST CONFIGURATION 
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FIGURE F-6 S-BAND TRANSPONDER TEST SET 





(Q-channel) signals is provided. it has the capability of 
high-accuracy group delay measurements of the transponder 
under test (the ST) in the TDRSS modes. The STTS, and the 
peripheral equipment, provide similar information in the 
TDRSS mode as that presently provided by the CTV's in the 
GSTDN modes of operation. Some of the operating parameters 
to be tested are the following; 

a. RF link thresholds and margin; 

b. Frequency and phase stabilities; 

c. Signal spectrum analysis; 

d. Modulation characteristics; 

e. Command and ranging verification; 

f. Telemetry decoding verification. 

3.3 S-BAMD SPREAD SPECTRUM TRANSPONDER 

The SSST is a NASA standard multiple access TDRSS 
user satellite transponder, its main functions in the CTV's 
are to check the operability of the STTS, and to emulate a 
SUT as a means of fault isolation should a pr jblem in the 
relay mode occur. To enable the SSST to operate on other 
frequencies in the single access mode in the TDRSG-assigned 
spectrum, an external modification to the system is being 
developed. To the full extent of its designed capability, 
the SSST will be used in the Ku-band range by the use of 
appropriate up and down converters. A command detector unit 
external to the transponder will be provided. 

3.4 COMPATABILITY TEST VAN APPLICATIONS 

At present, due to the time frame and TDRSS schedule, 
the functional uses of the CTV are still under question. It 
is known however that the CTV will be used in the A&V tests. 
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The CTV will be required for the following tests at the SSM 
Contractors integration facilities during the A&v test: 

• SSM Subsystem Functional and l/F verification 
tests; 

• ST Functional test; 

c Electromagnetic Compatibility test; 

• ST Thermal Vacuum/Thermal Balance test; 

• ST Pre~ship Functional test/Launch and Orbital 
verification Dress Rehearsal. 

ST/TDRSS compatibility will be demonstrated during 
the above tests. The CTV will also be required for ground 
system checkout, STOCC compatability, and fault isolation 
during pre-launch and launch support at KSC. 
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APPENDIX a 


TEST/SIMULATION EVENTS 

NASA dccu!Bdnt.ation concerning the Implementation of the 
entire ST ground system indicated a number of significant 
test and simulation events. Table G-1 , ST Teat/Simulation 
Schedule, represents these events depicting the relative' 
time frame of their occurances. Four of these events have 
been identified by NASA (code 500) as key to the 
implementation of the STOMS. These are the Verification and 
Acceptance Program (VAP), STOMS Readiness, ST 
Mission Operations procedure development, and Mission 
Simulation. The STOMS Test and Verification (TAV) has been 
substituted for the STOMS Readiness as a key event, with the 
assumption that the STOMS Readiness will be primarily an 
analysis and review of the TAV. Three other key events were 
identified: Lockheed Missile and Space Company, Inc. (LMSC) 

Assembly and Verification (A4V): Science Operations Ground 

System (SOGS) Integration and Test (I4T); and Mission 
Operations Ground System (MOGS) I4T. All of these have been 
identified in various NASA documents as key test and 
simulation events. 

The seven major test and simulation events (VAP, TAV, 
AAV, SOGS lAT, Mission Operation procedure development, MOGS 
lAT, and Mission Simulation) and their interface functional 
requirements are described in the following subsections. 

1 . VERIFICATION AND ACCEPTANCE PROGRAM (VAP) 

The primary objective of the VAP is to verify the 
mechanical, electrical, and operational aspects of the 
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SI'S and to ensure compatibility with the other SI and the 
SI C&OH interface. The VAP test will consist of utilizing a 
flight SI C&OH system, supplied by International Business 
Machines, for control command and data processing. A VAP 
Ground System Ccmiputer and SSM simulator will be used to 
interface the SI C&DH, and the POCC. The simulator will be 
connected via MASCOM from the VAP testing area in GSFC 
building 7 to the POCC area in GSFC building 14. The VAP 
Configuration is shown in Figure G-1. 

The VAP testing will provide information for pre- 
liminary validation of the Si's loads and responses to 
finalize the SI designs. 

VAP testing will also verify the compatibility of the 
Si's with the SI C&OH interfaces. 

The purpose of the POCC participation is to: 

• Demonstrate POCC compatibility with the SI C&DH and 
SI operation; 

e Verify POCC command generation for SI C&DH and SI 
operation as early as possible; 

• Verify POCC science and SI engineering data hand- 
ling, processing and display capability to the 
POCC; 

• Record real science data for later use in system 
development activities. 

A partially operational POCC will be implemented with 
all support capabilities necessary for VAP testing. This 
support will be available prior to the scheduled start of 
VAP testing. The items listed below must be operational for 
POCC VAP test participation: 

• Display Capability for Engineering Telemetry 
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FIGURE G-1 VERIFICATION AND ACCEPTANCE PROGRAM 













• Telemetry Data Processing for both Engineering and 
Science Data 

• Command Data Processing including On-Board Computer 
Load Transmission Software 

• PORTS Systems Test and Operation Language (PSTOL) 
Capability 

The functional requirements of the element interface 
relative to VAP testing are discussed under Section 5 » 
Functional Interface Requirements. The VAP testing comprises 
only a portion of the requirements for the.ST and the POCC. 


2. STOMS TEST AND VERIFICATION 

The functional requirements to be met under the Test 
and verification (TAV) are not only those imposed for each 
system element within STOMS # but also the requirement that 
these elements/ when combined/ function as a total system* 
The major element interfaces to be tested under the TAV 
event/ are the NCC/ NGT-NASCOM/ TDRSS/ OSCF , DCF, MSFC 
Simulator, and the pocC (see Figure G-2) . Under the STOMS 
implementation effort the POCC functional requirements are 
tested during the PORTS and PASS integration and test 
events. The DCF, MSFC Simulator and ST functional require- 
ments are also tested under their specific integration and 
test events or, in the case of ST itself/ during ST Assembly 
and verification (A&V) at LMSC. 

The NASA institutional elements/ i.e./ NCC/ NGT-NASCOM/ 
TDRSS/ and the OSFC are multimission support facilities and 
will have been tested as individual elements and exercised 
considerably by similar satellite projects prior to the TAV. 
However/ these elements will be tested for ST unique func- 
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tions during the verification of other elements within the 
STOMS. 


The STOMS TAV encompasses all activities associated 
with combining the major elements into the STOMS and with 
verifying STOMS operation. The TAV activities will be 
conducted in three phases. Phase I will consist of sequen- 
tially testing the interfacing hardware and software and 
verifying that the specific interface being tested complies 
with the related ICD. The use of both real and simulated 
SI data# spacecraft data# commands# schedules and Controlled 
Test Data Sets (CTDS) will be required. 

Phase II will be a systems engineering test to verify 
the various command# data and engineering strings as well as 
support functions. This will be a total test including 
verification of system reaction to anoroaJies. Controlled 
Test Data Sets will include predefined error inducing 
data. 

Phase III will be a mission oriented system perfor- 
mance test to verify full computer loading and timelines. 
All STOMS elements and interfaces will be exercised in a 
near normal operational environment. The ability of the 
STOMS to respond to element and sub-element failure will 
also be tested during this phase. 

Relative to the element interfaces previously de- 
fined under Section 5, Functional Interface Requirements, the 
STOMS TAV will test all of the element interfaces. 


3. ASSEMBLY AND VERIFICATION 

ST integration testing of the flight hardware is 
accomplished at the LMSC# Sunnyvale# California. This 
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integration test set leads to ST interface verification and 
consists of several carefully planned and integrated test 
sequences performed to demonstrate the integrity and capa- 
bility of an integrated ST. The configuration for Assembly 
and verification is shown in Figure G-3. 

The integration site (LMSC) test are as follows: 

1. SSM Subsystem Functional and Interface Verifica- 
tion Tests . 

This test is the initial ambient functional system 
test which permits early verification of the Si's 
and major interfaces. 

2. ST Functional Test . 

This test will be designed to verify the functional 
performance parameters of the ST. 

3 . Electromagnetic Compatibility Tests . 

The tests will monitor the predetermined critical 
interface circuits and power paths « and verify 
safety margins, sensitivity and interference on 
these circuits. 

4 . ST Mission Simulation and STOCC Compatibility 
Tests . 

(The ST Mission Simulation is not to be confused 
with the Mission Simulation for the ground support 
system.) The objectives of these tests are: 
(1) verification of satisfactory ST operation 
during simulated mission sequences; (2) verifica- 
tion of the compatibility of the deployment support 
equipment; and, (3) verification of the compati- 
bility of the ST with the STOCC/TDRSS/NASCOM. 

5. ST Thermal Vacuum/Therroal Balance Tests . 

The objectives of these tests are: (1) to detect 

latent material and workmanship defects under 
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therAial vacuum stress that are not evident in 
ambient testing; (2) to demonstrate ST thermal 
control system ability to control temperature 
excursions within mission thermal limits; and (3) 
to confirm the analytical model prediction capa- 
bility. 

6 « ST Pre-Ship Function Test/Launch and Orbital 
Verif icat.,on Dress Rehearsal ! 

This functional tist will contain representative 
sequences that will be used by the STOCC ( in Launch 
Site Operations and Orbital Verification). The 
subsequent dress rehearsal sequences will be 
designed arounc environmental constraints and 
planned ST cor.f iguration at Launch Site. 

Relative to the element interfaces previously defined 
under Section 5# Functional Interface Reauirements, AkV will 
test all of the POCC interfaces. 

4. SCIENCE OPERATIONS GROUND SYSTEM INTEGRATION AND TEST 

The SOGS is comprised of the hardware and software* 
located at the Science Support Center (SSC) and the ST 
Science Institute Facility (ST 3cIF) . The combined SSC and 
ST SciF hardware and software specified above will be 
developed under the SOGS contract. Figure G-4 illustrates 
the SOGS configuration. 

The SSC will be co-located with the POCC at the GSFC, 
and perform detailed science scheduling^ manage the transfer 
of data between the SSC and the ST SclF, support the POCC in 
system anomaly investigation / and conduct limited real-time 
science operations. The ST ScIF will conduct the program to 


*NOTE: Not included is the Guide Star Selection Software 

(GSSS) and the SI analysis software developed 
by the Scl. 
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support scientific observations » including the selection of 
scientific programs, observation planning, primary real-time 
science operations, science data processing and archiving, 
Scientific Instrument (SI) trend analysis, science data 
analysis, and product generation. 

The SOGS I&T Plan and Procedure have not been de- 
veloped as of this report time. However, the assumption is 
made that the I&T will be similar in nature to the STOMS TAV 
and MCXSS I&T. The exception to both of these examples is 
that the SOGS will be developed by one contractor with all 
internal interfaces being the responsibility of that con- 
tractor. The SOGS contractor will integrate the hardware 
and software, develop the test plans and procedures, dem- 
onstrate the system, and provide the reports. 

The SOGS external interfaces are those interfaces 
with the STOMS, as defined under the POCC and DCF Interface 
Functional Requirements (see Section 3, Functional Require- 
ments for Element Interface), and with the Science Institute 
software. What is referred to in this document as the 
Science Institute software is the Guide Star Selection 
Software and science data analysis software under the 
responsibility of the Scl contractor. 

The overall objective of the SOGS I&T will be to 
demonstrate the system's capability to perform all functions 
as defined in the specifications. 

Relative to the element interfaces previously de- 
fined under Section 3, Functional Requirements for Element 
Interfaces, the SOGS will test a partial subset of the POCC 
and DCF element interfaces. 

5. ST MISSION OPERATIONS PROCEDURE DEVELOPMENT 

The ST Mission Operations will be conducted by using 
procedures developed primarily by the MOC contractor through 
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liaison with the SCXSS, Scl# other ST contractors and NASA. 
These procedures are divided into three categories: (1) 
operations procedures (OPs) for the ST; (2) machine-execut- 
able procedures which will run on the POCC equipment; and 
(3) non-machine executable procedures called operations 
Directives (ODs) which define action to be taken by the 
operations staff. 

The OPS are English language procedures written from 
the operations rather than the design point of view. 

All machine executable procedures will be in PSTOL, 
a PORTS version of the System Test and Operations Language 
(STOL). These procedures shall normally be used by MOC and 
Scl personnel for all ST command generation, ST fault 
isolation, ST activation/deactivation, ST performance 
monitoring, acquisition of data, and ST contingency opera- 
tions. 

Operacional Data (OD) will include procedures for 
reporting of spacecraft problems, malfunctions, or failures, 
and their solutions or corrections; analyses and projections 
which may indicate failure-prone components or equipment, or 
their long-term degradation; spacecraft failure analysis and 
malfunction diagnosis procedures which will isolate and 
identify end-point failures, degradations leading to fail- 
ures, and probable propagation routes of failures through 
components or subsystems; and routine operations. The ODs 
will specify roles and responsibilities, functions, inter- 
faces and schedules, and detail the step-by-step tests 
necessary to accomplish ST mission operations. 

Mission Operations Procedure Development is not a 
test of the interfaces of STOMS although some of the proce- 
dures will be used in interface testing. Procedures may be 


developed by using input from the VAP» A&V and other test 
and simulation events. 

6. MISSION OPERATIONS GROUND SYSTEM INTEGRATION AND TEST 

The MOGS I&T encompasse'* all I&T activities associated 
with uniting the ST ground system elements into MOGS and 
verifying MOGS operation. MOGS is comprised of two major 
elements/ the Space Telescope Observatory Managements 
System (STOMS) and the Science Operations Ground System 
(SOGS) plus the Space Telescope Science Institute (ST Scl) 
developed software. The MOGS is illustrated in Figure G-5. 
MOGS I&T is to be accomplished in two phases. Phase I 
includes the integration and test of the interfacing hard- 
ware and software and the testing and verification that the 
interface complies with the related ICD. The second phase 
is the operational verification of the MOGS. 

Phase I will use relatively small components of each 
of the major elements to verify the compatibility across the 
specific interfaces being tested. Preparation of the test 
requirements/ plans and procedures for each Phase I test 
will be done by the same organization that has maintained 
and developed the related ICDs. Each organization shall 
support the test with the necessary materials/ test reports 
and test and operations personnel. 

Phase II will be conducted using large components 
of each of the major elements to verify the operation of the 
MOGS. The operation personnel to perform these tests will 
be provided by the Missions Operations contractor and the 
Scl Contractor. The above contractors will provide test 
requirements plans/ procedures/ and reports. This phase 
will include multiple interface testing with the use of 
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simulated and real ST data. MOGS data handling capacity and 
the ability of the MOGS to respond to system failures will 
also be tested. 

The STOMS interfaces of concern are the interfaces 
between STOMS and SOGS. The functional requirements of 
these interfaces are listed below: 

• Spacecraft operations and constraint data from STOMS 
to SOGS; 

• STOMS receipt of science mission specifications from 
SOGS to STOMS; 

e STOMS transmission of mission schedule parameters 
and timelines to SOGS; 

• STOMS transmission of science (including astrometry) 
and SI and SI C&DH engineering data to SOGS; 

• STOMS receipt of command requests from SOGS; 

• ST Status display from STOMS to SOGS via CCTV; 

• Transmission of captured Science data from STOMS to 
SOGS. 

The MOGS liT will test only a partial subset of the POCC 
and DCF element interfaces. 

7. MISSION SIMULATION 

The Mission Simulation is a functional test of the 
total ground system and will involve both the MOC and the 
Scl. Scenarios that will simulate "real time" operations 
will be developed to provide for rehearsal of prelaunch 
operations, deployment, orbit verification, routine opera- 
tions and contingency operations. 
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All POCC related mission simulation procedures will 
be developed by the MOC. SOGS related mission simulation 
procedures will be developed by the Scl. 

Maximum use will be made of the ST simulator and 
recorded ST data. Fault data shall be used to simulate 
contingency operations. During the actual simulations, the 
MOC and Scl provide all personnel for those functions which 
are routinely staffed by the MOC and Scl during normal 
operations. 

The Mission Simulation is not to be confused with 
the ST Simulation at the LMSC for the A and V. The opera- 
tional use of all the element interfaces will be used as 
defined under Section 5, Functional Interface Requirements. 
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I The following pages represent examples of three CTDSs 

■for the STOMS TAV. Reference Appendix E, Requirement s/CTDS 
I Matrices, for the correlation between these and other CTDSs 
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CONTROLLED TEST DATA SET - CTDS 
NO. Mil - ENGINEERING DATA FROM ST SIMULATOR 


1.0 INTRODUCTION 

This Interface is a simulated "Q" channel which supplies 
simulated engineering data from the ST Simulator at MSFC to the POCC. 
This is a test data stream which is used for verification of the 
POCC capabilities to receive and process ST engineering data. 


2.0 CONTENT 


The data stream contains engineering telemetry information 
which represents all systems of the ST and its payload. Space 
Telescope Health and Status Monitor Listings are given in Appendix 
B of Space Telescope Mission Operations Requirements OP-01 Volume 
III, document no. 4171847F LMSC. The telemetry data stream 
generated by the ST Simulator is developed to contain data from all 
of the monitored points listed in that document. 


3.0 FORMAT 

There are three programmable and two fixed formats which may 
be used for transmission of telemetry data from the ST. The ST 
Simulator data stream may be formatted according to any of these 
formats. A brief description of each of the formats is given below; 

a. Deployment Format . The deployment format is a 500 bps, 
software controlled, programmable format designed to be 
used during deployment operations when only the LCAs are 
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available. The format structure provides 125 elght-blt 
words per minor frame and 20 minor frames per major 
frame. 

b. Basic Format . The basic format Is a 4.0 kbps» software 
controlled, programmable format designed to be used 
during normal day-to-day ST operations. The format 
structure provides 250 elght-blt words per minor frame 
and 120 minor frames per major frame. 

c. Diagnostic Format . The diagnostic format Is a 32.0 kbps, 
software controlled, programmable format designed to pro- 
vide data at a faster rate for OTA and SSM performance 
diagnosis or evaluation. The format structure provides 
200 elght-blt words per minor frame and 1200 minor frames 
per major frame. 

d. 4.0 kbps Fixed Format . This is a fixed format stored in 
DMS read-only memory (ROM) that Is autonomously selected 
by the DMS In the event of a DF 224 computer failure. 

The format structure provides 125 eight-bit words per 
minor frame and 20 minor frames per major frame. 

e. 500 bps Fixed Format . This is a fixed format stored in 
DMS ROM that Is selected by grouad command If for any 
reason the other formats are not available. The format 
is designed to provide the "bare bones" information 
necessary to evaluate essential SSM functions, and to 
identify critical ST modes and problem areas during 
severe contingency conditions. The format structure 
provides 125 eight-bit words per minor frame and 20 
minor frames per major frame. 
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4.0 PHYSICAL INTERFACE REQUIREMENTS 


Simulated telemetry data is received at the POCC on the 
return path of the 56 Kb/s full duplex NASCOM channel which is 
used for transmitting command data to the ST Simulator. The 
telemetry data rates are 0.5, 4.0 and 32.0 Eb/s. 

5.0 VOLUME /SCHEDULING (TBD) 


Volume and scheduling of simulated telemetry data Is depen- 
dent upon the level of testing to be accomplished. 


6.0 SPECIFICATIONS (TBD) 


The exact measurements to be used for ST Health and Status 
monitoring In the POCC will be selected by POCC operations 
personnel. The specifics of the simulated telemetry data stream 
will necessarily be derived from the POCC requirements. 


7.0 IMPLEMENTATION (TBR ) 

The implementation of the test telemetry data flow will be 
initiated by the issuance of a simulation test order. This order 
will list all required hardware, software and procedures giving 
the version /revision levels applicable to the test to be performed. 
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9. LIST ALL DOCUMENTS, CONTROLLED STORAGE MEDIA, ETC. REQUI 
DATA SET. 


TITLE 


NUMBER 


REVISION 


ST SIMULATOR OPERATORS PROCEDURE 


PORTS SIMULATION SUPPORT OPERATORS PROCEDURE 
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CONTROLLED TEST DATA SET - CTDS 
NO. M12 - DECnet SERVICES, ST SIMULATOR 


1.0 INTRODUCTION 


Communications between the two computers at NSFC and the 
Simulator Support Computer at the POCC take place via this inter- 
face. The DECnet family consists of hardware and software which 
provides networking capability between Digital Equipment Corpora- 
tion (DEC) computers. In this particular application the VAX 11/780 
Simulator Support Computer at the POCC receives commands and 
instructions via the DEC net link with the PDP 11/70 in the ST 
Simulator at MSEC. The facility supports the generation of science 
data streams and simulated memory dumps. 

2.0 CONTENT 


The data stream contains program information which controls 
the playback of pre-recorded science data and reformats it into 
NASCOM 4800 bit block format. The instructions and commands are 
transmitted according to the protocol of the Digital Data Communi- 
cations Message Protocol (DDCMP). 


3.0 FORMAT 

The data transferred via this interface is formatted according 
to the VAX/VMS command language or any VAX-11 programming language. 
Communications may take place via direct commands from terminals 
at either end of the network or between processes of the applica- 
tions program. 
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4.0 PHYSICAL INTERFACE REQUIREMENTS 


The physical interface takes place between Network Controllers 
(DMC«11). These devices respond to program and operating system 
commands and automatically synchronize on the data, error check 
it and reformat it for communications using DDCMP rules. Trans- 
mission of data may occur at up to 19,200 b/s using EIA RS 232C 
standard interface. 


5.0 VOLUME /SCHEDULING 
TBD 

6.0 SPECIFICATIONS 

Specifications for the generation of the programs which 
control the playback of science data will be developed by MSFC. 


7.0 IMPLEMENTATION 


The implementation of the DECnet data flow will be initiated 
by the issuance of a simulation test order. This order will list 
all required osftware and procedures given the version/rev ision 
levels applicable to the test to be performed. 
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CONTROLLED TEST DATA SET - CTDS 
NO. P81 - COMMAND DATA TO ST SIMULATOR 


1.0 INTRODUCTION 


The purpose of this interface is to verify the capability 
of the POCC to generate and correctly format commands to the ST. 
These commands control the spacecraft as well as the instruments 
on-board. The command data stream sent to the ST Simulator at MSEC 
is generated by the PORTS using software which has been developed 
off-line. This software produces commands in sufficient variety 
and quantity to extensively test the PORTS command generation 
capabilities. 

2.0 CONTENT 


The command data stream contains both STORED PROGRAM COMMAND 
(SPC) blocks and REAL TIME COMMAND (RTC). The SPC blocks contain 
data for loading into either the DF224 or the NSSC-1. These 
commands are time tagged for execution at a later time. The SPC 
for the two computers (DF224 and NSSC-1) are not intermixed in any 
one data block. 

Categories of commands intended for execution by the on-board 
subsystems are listed below, with the items effected by the commands. 

o All Support System Module (SSM) subsystems which includes: 

1. Instrumentation and Communications - commands for 
control of HGA and switches which select communica- 
tions systems elements. 
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2. Pointing Control Subsystem (PCS) - commands control 
the attitude changes of on-board instruments. 

3. Electricl Power Subsystem (EPS) - commands control 
the selection and deployment of solar arrays for 
battery charging; also change trip points of charge 
control relays. 

4. Safing System - commands which cause the entry into, 
or deactivation of the Safing System. 

5. Data Management Subsystem (DMS) - commands which 
control the DMS in its operation with other sub- 
systems or the acceptance and loading of computer 
load data. 

o Optical Telescope Assembly (OTA) - discrete commands which 
directly or indirectly activate relays, or serial multi- 
bit commands, used to input engineering values. 

o Scientific Instruments Control and Data Handling (SIC k DH) 
commands which are required in the operational use of the 
scientific instruments. 

3.0 FORMAT 


All ST commands are formatted into 48 bit command words. 

The first seven bits are the spacecraft address; the last seven 
bits an error protection Hamming Code. 

The DF224, SPC and software updates are assembled with the 
first word in each block providing memory starting address and block 
length. The NS8C-1 has the block length in the first word and the 
starting address in the second word. The last word in each block 
is a ground computed checksum. For the DF224 (but not the NSSC-1) 
memory locations are replaced with data block or table number in 
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data updates. All command words are formatted into 4800 bit 

NASCOM blocks and each block is preceded by a 48 bit synchronization 

word. 


4.0 PHYSICAL INTERFACE REQUIREMENTS 

Command data is transmitted to the simulator via the forward 
path of a full duplex 56 Kb/s NASCOM channel at data rates of 0.125 
and 1.0 Kb/s. The electrical characteristics of the line meet £1A 
RS-422. 

5.0 VOLUME /SCHEDULING 


Volume and scheduling of simulated command data is dependent 
upon the level of testing to be accomplished. 

6.0 SPECIFICATIONS 


Specifications for the generation of command data to be 
used in verification of the PORTS system will be developed by the 
PORTS contractor. Commands shall be produced for all ST subsystems 
as well as memory load blocks for both DF224 and NSSC-1 computers. 


7.0 IMPLEMENTATION 


The Implementation of the test command data flow will be 
initiated by the issuance of a simulation test order. This order 
will list all required software and procedures giving the version/ 
revision levels applicable to the test to be performed. 
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INTERFACE CONTROL DOCUMENTS 


APPENDIX I 

INTERFACE CONTROL DOCUMENT 


DOCUMENT TITLE 

DOCUMENT 

NUMBER 

DEVELOPER 

SUPPORT 

STATUS 

PORTS to NOT NASCOM 


PORTS 

840 

N/A 

PORTS to NCC 


PORTS 

850 

N/A 

PORTS to VAP 

SF-ICD-20 

PORTS 

440 

N/A 

PORTS to A&V 

ST-ICD-24 

PORTS 

MSFC 

N/A 

PORTS to Simulator 

ST-ICD-28 

PORTS 

PORTS 

N/A 

PORTS to DCF 


PORTS 

DCF 

N/A 

PORTS to SSC (OLS) 


PORTS 

SOGS 

N/A 

PORTS to MPT 


PORTS 

MPT 

N/A 

PORTS to PE 

ST- I CD- 25 

PORTS 

MSFC 

N/A 

PORTS to LMSC 

ST-ICD-25 

PORTS 

MSFC 

N/A 

PORTS to BFEC 

ST- I CP- 2 5 

PORTS 

MSFC 

N/A 

PORTS to Project 
Data Base 

ST-ICD-26 

PORTS 

440 

N/A 

PORTS to CTV 

ST- I CD- 23 

PORTS 

860 

N/A 

PORTS to OSCF 


PORTS 

OSCF 

N/A 

PORTS to PASS 

ST- I CD- 11 

PORTS 

PASS 

N/A 

PORTS to CCTV/Data 
Comm 


PORTS 

513 

N/A 

PORTS to GSTDN 


PORTS 

800 

N/A 

PASS to SSC 


SOGS 

PASS 

N/A 

PASS to MPT 


PASS 

MPT 

^ N/A 

PASS to OSCF 


PASS 

OSCF 

I N/A 

PASS to project 
Data Base 


PASS 

MSFC 

N/A 

PASS to DCF 


DCF 

PASS 

N/A 

PASS to External 
VF224 Loads 


PASS 

MSFC 

N/A 


I-l 




DOCUMENT 




DOCUMENT TITLE 

NUMBER 

DEVELOPER 

SUPPORT 

STATUS 

PASS to External 
NSSC-1 Loads 


PASS 

MSFC 


DCF to NCC 


DCF 

850 


DCF to NGT-NASCOM 


DCF 

840 


DCF to SCIF 

ST-ICD-13 

DCF 

SOGS 


POCC to SCC- 
Coininunicator 

ST-ICD-12 

PORTS 

SOGS 

N/A 

POCC to VAP Data 
Base 

ST- 1 CD- 21 

PORTS 

IBM 

N/A 

POCC to VAP Telemetry 
Magnetic Tape 

ST-ICD-22 

PORTS 

IBM 

N/A 

POCC to LMSC A&V 
Test Telemetry 
Magnetic Tape 

ST-ICD-27 

PORTS 

LMSC 

N/A 

Ground Communications 

ST-ICD-18 

GSFC/ST 

Project 

Code 

800 



NOTE: N/A indicates not available. 
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GLOSSARY 


Ancillary Data - Additional, "non-Scientif ic Instru- 
ment (SI)" data which are required to facilitate the analy- 
sis and reduction of science data and SI engineering data. 
These data include: time data, programmatic data, attitude 
data, ephemeris data, and non-SI engineering data obtained 
on special request. 

Astrometry Science Data - Data derived from the Sup- 
port System Module (SSM) engineering data stream, combined 
with appropriate header data, formatted into a science data 
stream, and delivered as science data. The bit error rate 
and data accountability standards normally applied to the 
SSM engineering data are applied even when this data stream 
is used to derive astrometry science data. 

Constraint - An operational limitation imposed on 
the use of the hardware that must not be violated in either 
planning or operations. This includes features or charac- 
teristics of the hardware inherent to the design which, if 
violated, could cause physical damage. 

DDCMP - (Digital Data Communications Message proto- 
cols) These protocols control message transmission over a 
physical communications link by using: (1) Cyclic Redun- 
dance Check (CRC) for error detecting, (2) retransmission 
for error corrections; and (3) numbered data messages to 
ensure sequential transfer of data. DDCMP is a Digital 
Equipment Corporation development used exclusively with 
DECnet implementation. 


DECnet - A family of network products developed by 
Digital Equipment Corporation that adds networking capa- 
bility to DIGITAL'S computer families and operating systems. 
Using DECnet, various kinds of computer system networks can 
be constructed to facilitate remote communications, resource 
sharing, and distributed computation DECnet is highly 
modular and flexible. It can be viewed as a set of tools or 
services from which a user selects those appropriate to 
build a network to satisfy the requirements of a particular 
application. 

Ground Control Message Requests - A request trans- 
mitted to TDRSS via NCC from the POCC for the control and 
administration of site support ground functions, initiates 
reconfiguration of scheduled services or activates speacial 
procedures at the TDRSS ground terminal. 

Mission Planning Terminal - The primary function 
of the Mission planning Terminal (MPT) is to act as the 
interface for the POCC in obtaining STDN support from the 
NCC. The MPT provides POCC users with the capability to 
communicate with the Network Control Center Data Systems 
(NCCDS) in the TDRSS era. 

This function provides the POCCS with the capability 
to convert their mission planning requirements into STDN 
service requirements, to communicate these requirements to 
the NCC, to view, confirm and modify the resultant STDN 
schedule, to receive and distribute schedules to the mission 
users, to alert poCCs service impacts from NCC, and to 
exchange portions of the planning/scheduling data bases. 


Mission Schedule - The composite of all science and 
spacecraft operational elements, orbital events, data link 
opportunities, etc., which govern ST operations. The ST 
mission schedule is the master schedule from which ST 
commands are derived and generated. 

Mission Timeline - The listing, in hardcopy and/or 
machine readable media, of the specifications of the se- 
quence of events contained in the mission schedule. 

NGT-NASCOM - The component of the NASA Ground Terminal 
(NGT) that provides TDRSS communication transport services 
between the NGT at White Sands and the POCCs. 

Operation Data Messages - Enables administrative 
communication between the NCC and its external interfaces; 
provides information and direction or requests information 
and direction. 

performance Data - provides link status information 
which indicates how well the system is supporting an event. 

Science Data Streams - Data originating in the ST 
that contain the observational output of one or more of the 
five Sis, Sl-unique data logs generated in the Sis or in the 
NSSC-1, the Standard Header packet, the NSSC-1 Status Buffer 
contents, or NSSC-1 memory dumps. These data are transmit- 
ted in real-time at either 4 kbps or 1 Mbps or stored on a 
tape recorder for later transmission. When recorded, the 4 
kbps stream is upconverted; a 32 kbps stream, capable of 


being recorded but not available in real-time, is not 
upconverted. Playback of recorded data occurs at a 1 Mbps 
rate. 


* Science Mission Specification - The detailed specifi- 
cation of science observations giving the particulars of all 
science-related functions, the sequence of observations and 
the command requests and parameters describing each observa- 
tion. Each element of the science mission specifications is 
time-tagged in correspondence with its anticipated position 
in the ST mission timeline. 

Spaceflight Tracking and Data Network (STDN) - The 
Tracking and Data Relay Satellite System (TDRSS), the Ground 
Spaceflight Tracking and Data Network (GSTDN), the Network 
Control Center (NCC) and the NASA Communications Network. 
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